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EXECUTIVE  SUMMARY 


This  investigation  addresses  the  problem  of  formulating  an 
integrated  decision  aid  from  several  functionally  related  decision  aids 
developed  as  part  of  the  Operational  Decision  Aids  program  sponsored  by 
the  Office  of  Naval  Research.  These  aids  include: 

The  Integrated  Sciences  Corp.  Route  Planner  - An  aid  that  assists 
the  decision  maker  in  selecting  the  optimal  air  route  from 
carrier  to  target  through  a radar  detection  field.  The  criterion 
for  optimization  is  a function  of  detection  probability  and  fuel 
consumption. 

The  Analytics  Air  Strike  Timing  Decision  Aid— ASTDA  - An  aid  that 
assists  the  decision  maker  in  selecting  the  optimal  time  to  launch  a 
strike  as  a function  of  weather  and  force  readiness  factors  that 
impact  the  engagement  outcome. 

The  Decision-Science  Applications,  Electronic  Warfare  Decision  Aid-EWAR 
An  aid  that  assists  in  formulating  electromagnetic  emission  control 
plans  by  balancing  surveillance  coverage  benefits  and  information- 
given-away  costs. 


The  SRI  International  Strike  Outcome  Calculator-SOC  - An  aid  that 
estimates  the  consequences  of  alternate  courses-of-action  for  a 
carrier  based  air  strike  campaign,  using  a deterministic  engagement 
model  covering  both  adversaries'  operations  plans. 


Requirements  for  an  Integrated  Decision-Aiding  System 


The  aids  itemized  above  were  analyzed  with  respect  to  the  generic 
mission  problem  that  they  addressed,  the  specific  process  model  that  charac- 
terized the  engagement  (mission)  actions,  the  value  model  used  to  quantify 
measures  of  effectiveness,  the  variables  and  parameters  used  in  describing 


the  systems  and  decision  factors,  the  optimization  and  analysis  procedures 
utilized,  the  methods  used  to  display  outputs  to  the  decision  maker,  and  the 
roles  of  human  judgment  and  heuristics  assumed  in  the  decision  process. 
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Several  properties  that  an  integrated  decision  aid  should  exhibit 
were  identified.  These  properties  are:  consistency,  flexibility,  efficiency, 
validity,  extendi bility  and  understandability. 

The  mutual  compatibility  of  the  component  models  and  the  means  by 
which  they  interface  with  one  another  are  discussed. 

It  was  decided  that  the  integrated  aid  should  be  compatible  with  the 
diverse  styles  and  strategies  used  by  different  decision  makers  and  should 
permit  the  explicit  incorporation  of  the  user's  expertise  in  the  decision 
making  process.  Aid  features  should  be  implemented  as  user-controlled  options 
in  order  to  allow  the  aid  to  conform  to  the  needs  of  the  individual  user.  It 
should  be  possible  to  treat  all  data  and  processes  as  certain  and  deterministic 
according  to  the  characteristics  of  specific  situations  or,  optionally,  to 
consider  the  consequences  of  statistical  uncertainty  in  data  estimates  and 
process  events.  The  user  should  be  able  to  focus  only  on  the  features  of  a 
specific  decision  problem  from  a single  perspective  or,  alternatively,  con- 
figure the  aid  to  address  the  problems  of  both  adversaries  in  a war-game 
exercise.  An  optional  operator-aided  optimization  technique  based  on  a non- 
linear programming  aglorithm  might  eventually  be  added  to  the  integrated  system 
for  determining  an  optimal  strike  approach  route  and  this  technique  might  also 
be  extended  to  other  strike  planning  problems.  The  ability  to  examine  the 
intermediate  results  in  a process  (intraprocess  analysis)  and  to  analyze  the 
sensitivity  of  an  outcome  criterion  of  a process  to  the  principal  input  vari- 
ables (sensitivity  analysis)  should  be  available  so  that  the  decision  maker 
can  make  reliable  assignments  of  value  to  process  results.  Finally,  the  linkage 
between  short-term  action  and  longer  term  mission  goals  should  be  clearly  displayed. 

Conclusions 

The  four  problem-specific  aids  discussed  contain  effective  tech- 
niques applicable  to  an  integrated  aid.  Integrating  these  separate  aids 
necessitates  considerable  additional  work  to  achieve  the  required  compatibility 
in  their  overlapping  domains.  For  ASTDA,  EWAR  and  SOC  to  work  together,  a 


Li 


n 


consolidated  engagement  model  is  needed  that  will  replace  the  individual 
models;  the  consolidated  model  should  be  operable  in  both  deterministic  and 
stochastic  modes.  A common  procedure  for  valuing  strike  mission  results  is 
required  to  replace  the  separate  value  models  of  the  Route  Planner,  ASTDA, 
and  EWAR.  Variables  such  as  the  flight  altitude  of  the  strike  force  on 
approach  to  the  target,  the  duration  of  engagement  between  the  strike  force 
and  the  enemy  interceptor  force,  and  the  damage  levels  sustained  during  the 
engagement  must  be  incorporated  into  the  models  of  the  engagement  and  radar 
detection  processes  to  improve  their  operational  accuracy.  Standardized 
display  formats  should  be  adopted  for  tables,  graphs,  and  maps  offered  by 

. 

the  integrated  aid. 

I 

Recommendations 

Development  of  the  integrated  decision  aid  involves  a two 
pronged  effort  — a "top-down"  approach  in  which  the  task  force  objectives 
and  the  consequent  model  requirements  are  further  definitized  and  a "bottom- 
up"  approach  that  defines  a compatible  interface  between  the  component  decision 
aids.  As  a first  stage  of  integration,  an  integrated  aid  might  support  the 
planning  for  a single  air  strike  mission.  In  such  an  aid,  key  elements  of 
the  Route  Planner  and  ASTDA  would  be  combined  into  a higher  level  aid  known 
as  SCAMP-1  (Strike  Campaign  Planning  Decision  Aid  - Version  1).  This  aid 
would  be  upward  compatible,  allowing  features  of  EWAR  and  SOC  to  be  incor- 
porated in  future  development  efforts.  SCAMP-1  would  assist  in  a broad  range 
of  strike  time,  strike  force  complement,  and  target  assignments.  The  first 
step  in  the  development  of  SCAMP-1  would  be  the  adaptation  of  existing  process 
and  value  models.  This  step  can  be  accomplished  in  a short  time  because  the 
available  models  provide  most  of  the  necessary  components.  Subsequent 
development  phases  will  require  the  development  of  new  program  components 
to  achieve  an  efficient  extendible  system. 


r 


PRECEDING  PAGE  BLANK*NOT  FILhED 


1.  INTRODUCTION 


i 


<1 


!. 


II 

I! 


In  the  Operational  Decision  Aids  program,  the  Office  of  Naval 
Research  has  sponsored  the  development  of  a variety  of  decision  aids  for 
naval  command  and  control  decision  problems.  These  aids  have  been  designed 
to  assist  in  the  solution  of  various  tactical  decision  problems  thac  a task 
force  command  would  encounter  in  a wartime  environment.  Aids  have  been 
developed  for  the  specific  problems  of  determining  a flight  path  for  an  air 
strike  force,  selecting  a launch  time  for  an  air  strike,  developing  a com- 
prehensive plan  for  a battle  campaign,  and  constructing  and  analyzing  electro- 
magnetic emission  control  plans.  Two  general  purpose  aids  have  also  been 
developed,  one  to  construct  and  analyze  decision  tree  structures  and  another 
to  perform  Bayesian  updating  and  expected  value  calculations.  At  a more 
basic  level,  an  extensive  data  base  has  been  constructed  to  support  experi- 
mental versions  of  the  decision  aids  and  a sophisticated  superstructure 
has  been  developed  to  interface  the  user  with  the  data  base  and  the  aids. 
Together,  all  of  these  aids  and  supporting  systems  offer  assistance  to  the 
task  force  command  in  a wide  range  of  decisions  concerning  task  force 
operations. 

In  contemplating  the  simultaneous  installation  of  all  or  some  of 
these  decision  aiding  systems  in  a task  force  command  center,  there  are  a 
number  of  important  considerations  which  have  not  been  addressed  in  the 
development  of  any  single  aid.  These  considerations  bear  on  the  issue  of 
how  the  aiding  systems  interface  with  one  another,  both  in  concept  and  in 
practice.  On  the  practical  side,  there  are  questions  about  how  the  user 
accomplishes  the  transfer  of  data  from  one  system  to  another  in  cases  in 
which  two  or  more  aids  perform  related  functions  and  how  the  user  can 
implement  a component  of  one  system  (e.g.,  a Bayesian  updating  processor 
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or  a multi-variate  optimizing  algorithm)  to  perform  a related  function  for 
another  decision  aiding  system.  The  lack  of  an  adequate  interface  can  com- 
pletely block  any  complementary  use  of  distinct  systems  despite  obvious 
interrelations  between  the  real  situations  being  represented. 

Conceptual  interface  problems  can  arise  from  an  inconsistent 
interpretation  of  similar  concepts  by  different  aiding  systems.  The  same 
real-world  variable  might  be  defined  or  quantified  very  differently  in 
separate  systems,  thus  requiring  the  user  to  enter  the  same  data  repeatedly, 
each  time  according  to  a different  arbitrary  convention.  Distinct  systems 
that  deal  with  the  same  process  may  focus  on  different  descriptive  variables 
for  the  inputs  and  outputs  of  the  process,  and  they  will  almost  certainly 
employ  different  mathematical  models  for  the  same  process.  Different  levels 
of  details  and  degrees  of  aggregation  are  likely  to  be  represented  in  the 
input  and  output  variables  of  different  systems.  Thus,  the  lack  of  an 
effective  conceptual  interface  between  a set  of  functionally  related  aids 
can  generate  confusion  and  aggravation  on  the  part  of  the  user  because  he 
is  required  to  supply  more  input  data  than  appears  necessary  and  because  he 
is  pressed  to  interpret  a variety  of  conflicting  outputs.  Interface  problems 
at  the  conceptual  level  can  also  be  expected  to  interact  adversely  with  any 
mechanical  interface  problems  that  are  also  present,  thus  disposing  the 
user  to  operate  each  aiding  system  as  if  none  of  the  others  were  available. 


The  research  described  in  this  report  has  focused  on  the  identifica- 
tion and  solution  of  the  interface  problems  that  would  arise  from  the  collective 
implementation  of  the  four  ODA  decision  aids  which  deal  with  specific  tactical 
problems.  The  aids  to  be  interfaced  with  one  another  include  the  Route 
Planner  developed  by  Integrated  Sciences  Corporation,  the  Air  Strike  Timing 
Decision  Aid  (ASTDA)  developed  by  Analytics,  the  Electronic  Warfare  Decision 
Aid  (EWAR)  developed  by  Decision-Science  Applications,  Inc.,  and  the  Strike 
Outcome  Calculator  (SOC)  developed  by  SRI  International.  Attention  has  been 
restricted  to  these  problem-specific  aids  because  they  pose  more  substantial 
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interface  problems  than  the  more  general  systems  and  because  they  deal  with 
clearly  related  processes.  The  SOC  simulates  offensive  and  defensive  task 
force  operations  in  order  to  provide  estimates  of  the  results  of  protracted 
campaigns  directed  by  precise  contingency  plans.  The  EWAR  aid  simulates 
defensive  task  force  operations  to  predict  the  results  of  various  emission 
control  policies  in  specific  threat  situations.  ASTDA  simulates  single 
air  strike  missions  to  provide  estimates  of  the  outcomes  of  missions  launched 
at  different  times  and  manageable  evaluations  of  those  outcomes.  The  Route 
Planner  does  not  incorporate  any  simulation  process,  but  it  does  employ  a 
value  function  for  the  potential  effectiveness  of  a strike  mission  that 
approaches  a target  by  a particular  route  through  a field  of  enemy  radar 
stations.  Major  interface  problems  can  thus  be  expected  regarding  the  SOC 
and  EWAR  simulations  of  defensive  task  force  operations,  the  SOC  and  ASTDA 
simulations  of  offensive  task  force  operations,  and  between  the  Route  Planner 
and  ASTDA  identifications  of  the  factors  that  determine  the  strike  potential 
of  the  strike  force  upon  arriving  at  the  target. 

There  are  undoubtedly  many  ways  in  which  the  ODA  aids  could  be 
effectively  integrated  to  avoid  interface  problems.  Each  particular  problem 
can  be  resolved  by  adopting  the  mechanism  or  concept  of  any  one  aid  for  the 
integrated  system  or  by  developing  a new  compromise  feature  for  the  combined 
system.  In  order  to  resolve  just  the  more  serious  interface  problems,  sub- 
stantial modifications  will  have  to  be  made  to  all  of  the  component  aiding 
systems.  The  ultimate  extent  of  these  modifications  will  be  determined  by 
the  particular  interface  problems  that  are  addressed,  the  manner  in  which  the 
problems  are  resolved,  and  any  additional  system  development  that  is  under- 
taken. The  subject  of  additional  system  development  should  be  considered  in 
light  of  the  incomplete  or  experimental  status  of  all  of  the  systems  to  be 
integrated. 

The  first  step  in  the  development  of  an  integrated  aiding  system 
from  all  four  prototype  systems  is  the  careful  examination  of  each  component 
system.  Accordingly,  Section  2 of  this  report  offers  detailed  descriptions 
of  each  of  the  problem-specific  decision  aids  as  gleaned  from  available 
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documentation  and  conversation  with  the  aid  developers.  We  must  note  that 
the  observations,  interpretations  and  conclusions  that  are  expressed  through 
out  this  report,  and  in  Section  2 in  particular,  are  the  responsibility  of 
the  report  authors  alone  and  do  not  necessarily  represent  the  views  of  the 
developers  of  the  individual  decision  aids  or  of  the  ODA  steering  committee. 
Since  the  existing  documentation  for  the  decision  aids  varies  considerably 
in  organization  and  level  of  detail,  we  constructed  a single  general  outline 
for  the  discussion  of  all  of  the  aids  in  order  to  facilitate  comparisons 
between  them.  The  outline  is  designed  specifically  to  highlight  the  funda- 
mental differences  between  the  aiding  systems  which  must  be  resolved  as  the 
first  step  of  the  integration  process.  The  main  points  in  the  outline  of 
decision  aid  features  are  as  follows: 

• Identification  of  target  problems. 


— In  what  type  of  situation  and  what  timeframe  is  the  aid 
designed  to  be  used?  On  what  types  of  decision  options 
does  it  focus? 

Identification  of  process  models. 

--  Does  the  aid  incorporate  mathematical  models  of  any  real- 
world  processes  such  as  military  engagements  or  repair 
operations?  How  are  any  such  models  implemented? 

Identification  of  value  models. 

— Does  the  aid  determine  a numerical  value  for  each  decision 
option  to  represent  the  overall  desirability  of  that  option 
in  terms  of  the  objectives  of  the  decision  maker?  What 
mathematical  formulae  are  used  for  such  calculations? 

Description  of  variables  and  parameters. 

--  What  input  variables  and  parameter  estimates  are  required 
by  the  aid?  What  outputs  are  offered?  How  are  decision 
alternatives  represented?  How,  if  at  all,  is  uncertainty 
in  estimated  quantities  represented? 

Description  of  analysis  procedures. 

— Does  the  aid  provide  an  automatic  procedure  for  determining 
a configuration  of  input  variables  which  results  in  an 
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optimal  value  of  some  output  criterion?  Can  the  user 
examine  isolated  sensitivities  of  output  variables  to 
input  variables?  Are  other  auxiliary  analysis  techniques 
incorporated  in  the  aid?  What  are  the  mathematical  bases 
of  such  analyses? 

• Description  of  display  features. 

— What  display  techniques  are  used  to  convey  information  to 
the  user?  Is  data  displayed  in  tables  or  graphs?  How 
is  statistical  distribution  data  coded? 

• Discussion  of  the  role  of  human  judgment  and  heuristics. 

--  In  what  way  does  the  aid  complement  or  preempt  the  judgment 
of  the  user?  Can  the  aid  be  used  equally  effectively  with 
a variety  of  decision  making  strategies  or  does  it  dictate 
a single,  fixed  strategy?  Does  the  aid  require  the  user  to 
provide  any  estimates  that  he  cannot  make  reliably  and 
confidently? 


Following  the  description  of  the  individual  aids  in  Section  2,  we 
discuss  in  Section  3 the  specific  problems  that  are  addressed  in  the  inte- 
gration process.  These  problems  concern  the  issues  of  how  the  component 
systems  interface  with  one  another  and  also  some  important  shortcomings  in 
the  current  systems  with  regard  to  their  operational  objectives.  While  it 
is  appropriate  that  the  current  prototype  decision  aids  should  have  incor- 
porated some  simplifications  to  expedite  their  development  and  implementation, 
it  is  important  to  avoid  building  such  simplifications  into  the  integrated 
system  in  a manner  that  will  hide  the  simplifications  or  will  make  them  more 
difficult  to  rectify  in  subsequent  aid  development.  The  discussion  in  Section 
3 identifies  the  specific  areas  in  which  modifications  and  further  develop- 
ments of  system  features  should  be  considered  both  to  improve  the  interface 
between  component  systems  and  to  enhance  the  usefulness  of  the  integrated 
system. 


Descriptions  of  two  approaches  to  the  design  of  an  integrated 
decision  aiding  system  are  presented  in  Section  4.  The  first  approach, 
characterized  as  a bottom-up  design,  consists  of  piecing  together  the  available 
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decision  aiding  components  to  create  an  harmoniously  functioning  system.  A 
first  stage  application  of  this  approach  is  described  for  the  planning  of  a 
single  strike  mission.  The  second  approach,  termed  a top-down  design,  focuses 
on  the  problem  of  structuring  the  decision  situation.  The  basic  concept 
of  this  approach  is  to  conduct  a systematic  analysis  of  objectives  before 
proceeding  to  an  analysis  of  action  options  available  to  the  decision  maker. 
This  type  of  system  design  is  appropriate  for  expansion  of  the  integrated 
system  from  the  domain  of  single  strike  planning  to  that  of  comprehensive 
campaign  planning.  The  relationship  between  the  two  approaches  to  system 
design  is  represented  in  Figure  1-1. 

A general  software  structure  suitable  for  the  integrated  system  is 
presented  in  Section  5.  The  structure  calls  for  the  separation  of  the  decision 
aiding  system  into  the  distinct  component  functions  of  data  base  establishment,1 
problem  specification,  and  solution  description.  The  object  of  this  organiza- 
tion is  to  segregate  data  that  is  relatively  permanent  and  general  from  data 
that  is  transient  and  situation  specific.  At  the  same  time  this  structure 
facilitates  the  development  of  common  software  routines  for  performing 
related  data  input  and  analysis  functions  for  all  component  decision  aiding 
appl i cations. 

Finally,  conclusions  and  recommendations  for  further  development 
are  presented  in  Section  6.  It  is  suggested  that  both  the  bottom-up  and  top- 
down  approaches  to  system  development  be  pursued  in  parallel.  New  display  and 
analysis  techniques  for  strike  planning  should  be  developed  and  experimentally 
evaluated  as  one  effort  while  a structure  for  analyzing  task  force  goals  and 
their  relationship  to  decision  options  should  be  investigated  as  a separate 
effort.  The  end  result  of  these  two  approaches  together  should  be  an  inte- 
grated decision  aiding  system  that  both  addresses  the  real  needs  of  the 
decision  maker  and  makes  optimal  use  of  available  decision  aiding  technology. 
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Figure  1-1.  General  Approach  to  Development  of  an  Integrated  Decision-Aiding  System 


PRECEDING  PACK  BLAMC-NOT  71LMD 


2.  THE  PROBLEM-SPECIFIC  DECISION  AIDS 


2.1  ASTDA 

The  Air  Strike  Timing  Decision  Aid  (ASTDA)  developed  by  Analytics 
(Epstein  et.  al.,  1977;  Glenn  and  Zachary,  1978;  Epstein,  1978)  assists 
a Task  Force  Commander  (TFC)  and  his  staff  In  choosing  the  optimal  time  to 
launch  an  air  strike  mission,  given  uncertain  and  time-varying  predictions 
of  the  weather  and  force  readiness  conditions  that  would  obtain  at  the  time 
of  the  strike.  ASTDA  combines  user-supplied  probabilistic  predictions  of 

I 

weather  and  readiness  states  with  Information  from  an  extensive  data  base 
as  inputs  to  an  engagement  model  which  produces  statistical  estimates  of 
the  outcomes  that  would  result  from  launching  strikes  at  different  times. 

Outcomes  are  in  the  form  of  unit-specific  loss  estimates  for  each  type  of 
own  and  enemy  system.  A value  model  provides  an  aggregated  mission-achieve- 
ment score  based  on  these  outcomes.  Special  features  of  the  aid  enable  the 
user  to  test  the  sensitivity  of  loss  estimates  and  value  outputs  to  variations 
in  each  of  the  input  predictions  and  to  examine  the  distribution  of  losses 
over  the  various  parts  of  the  simulated  mission.  The  aid  is  interactive, 
with  a variety  of  tabular  and  color  graphic  displays  of  the  input  and  output 
data.  The  general  structure  of  ASTDA  is  represented  in  Figure  2-1. 

2.1.1  Target  Problem 

ASTDA  was  designed  to  aid  in  the  situation  in  which  a decision  to 
launch  an  air  strike  has  been  made  and  a strike  launch  window  (i.e.,  the 
total  range  of  possible  launch  times)  has  been  established,  but  the  precise 
time  to  launch  remains  to  be  resolved.  It  also  assumes  that  many  of  the 
details  of  the  strike,  in  addition  to  the  launch  window,  have  been  predetermined, 
such  as  the  type  of  strike,  the  optimal  aircraft  complement,  the  weapon  con- 
figurations, and  the  targets  to  be  attacked.  The  results  of  launching  at 
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various  times  in  the  strike  launch  window  are  affected  primarily  by  the 
different  weather  conditions  and  states  of  own  and  enemy  preparedness 
encountered  at  the  different  launch  times.  To  the  extent  that  extremely 
different  conditions  may  prevail  during  the  launch  window  than  those  expected 
when  the  Op  Orders  were  formed,  it  is  possible  the  the  decision  maker  may 
opt  to  change  some  of  the  predetermined  mission  parameters  or  even  decide 
not  to  launch  the  strike  at  all.  The  aid  incorporates  arbitrarily  fine- 
grained predictions  of  the  input  variables  (e.g.,  hour-by-hour  estimates  of 
weather  conditions  and  own  and  enemy  readiness)  and  generates  similarly 
detailed  predictions  of  the  results  of  the  strike.  The  primary  timeframe 
for  the  use  of  ASTDA  is  the  24  hour  period  preceding  the  strike  launch  window. 

2.1.2  Process  Model 

ASTDA  uses  a stochastic  engagement  model  to  produce  statistical 
estimates  of  the  results  of  strikes  launched  at  each  of  the  specified  times 
in  the  strike  launch  window.  The  model  predicts  the  results  of  a single 
carrier-based  air  strike  against  a defended  target.  The  strike  mission  is 
sub-divided  into  four  segments  — ingress  to  target,  engagement  at  the  target, 
egress  from  target,  and  landing  at  the  carrier  — each  of  which  is  modeled 
separately.  In  each  segment,  a probability  of  surviving  the  segment  is 
computed  for  a single  unit  of  each  type  of  Blue  (own)  and  Orange  (enemy) 
force  element.  Each  unit  of  a given  type  therefore  has  the  same  survival 
probability,  but  the  survival  of  each  unit  is  treated  as  an  independent 
Bernoulli  event  which  is  sampled  in  a Monte  Carlo  fashion.  This  procedure 
incorporates  the  uncertainty  inherent  in  a military  engagement  into  the 
results  of  the  model.  In  the  case  of  Blue  force  bombers,  survival  in  the 
ingress  segment  represents  survival  to  the  at-target  segment,  but  some  units 
not  surviving  may  successfully  abort  the  mission  by  jettisoning  their  ordnance 
and  returning  to  the  carrier.  These  possibilities  are  modeled  through  the 
computations  of  separate  probabilities  for  Bernoulli  events  representing 
success  or  failure  of  attempts  to  abort  the  mission  and  return  to  the  carrier. 
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The  inputs  to  the  engagement  model  are  the  numbers  of  Blue  aircraft 


of  each  type  successfully  launched,  the  numbers  of  each  type  of  Orange 
interceptor  encountered,  the  number  of  operational  Orange  defense  units  of 
each  type,  the  weather  condition  at  the  target  (at  the  time  the  aircraft 
arrives  there),  and  the  weather  condition  at  the  carrier  (at  the  time  the 
aircraft  returns  to  the  carrier).  These  values  are  sampled  from  their 
statistical  distributions  in  a Monte  Carlo  manner.  The  outputs  of  the  model 
are  unit-specific  loss  figures  for  each  type  of  Blue  and  Orange  system  (air- 
craft, defenses,  and  targets)  over  the  entire  mission.  The  model  is  run  a 
sufficient  number  of  times  to  generate  distributions  of  results  which  reflect 
the  uncertainty  contained  in  the  input  predictions  and  in  the  outcomes  of  the 
engagements  in  each  segment. 

2.1.3  Value  Model 

ASTDA  constructs  a composite  mission-achievement  score  ( utility ) 
from  the  results  of  each  run  of  the  engagement  model  through  the  use  of  its 
value  model.  The  utility  score  distribution  statistics  are  provided  to  the 
decision  maker  along  with  the  other  ASTDA  outputs.  The  utility  score  is  com- 
puted from  a value  model  which  evaluates  the  mission  as  a weighted  sum  of 
all  the  Blue  and  Orange  losses  during  the  mission.  The  weight  assigned 
to  each  type  of  unit  is  based  on  the  estimated  impact  of  the  loss  of  one 
unit  on  the  achievement  of  the  mission  objectives.  Thus,  Blue  aircraft  have 
negative  weights  (losing  a Blue  aircraft  reduces  the  achievement  of  mission 
objectives)  and  Orange  aircraft,  defenses  and  targets  have  positive  weights 
(destroying  Orange  resources  contributes  to  the  achievement  of  mission 
objectives).  The  relative  magnitudes  of  the  weights  indicate  the  relative 
importance  of  the  various  unit  types  on  a linear  value  scale.  ASTDA  assumes 
that  the  values  assigned  to  each  Blue  and  Orange  unit  on  this  scale  represent 
the  conmand  level  value  judgments  within  which  the  decision  maker  must  work. 

2.1.4  Decision  Variables,  System  Variables,  and  System  Parameters 

ASTDA  provides  the  decision  maker  with  a single  decision  variable, 

the  strike  launch  time  to  be  chosen.  It  divides  the  strike  launch  window 
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into  two  to  six  equal  intervals  (depending  on  the  width  of  the  window),  and 
presents  all  input  and  output  information  in  terms  of  the  starting  point  of 
each  of  these  intervals.  One  hour  intervals  are  employed  in  the  current 
version  of  ASTDA,  but  other  interval  periods  could  be  implemented. 

ASTDA's  input  variables  represent  those  independent  characteristics 
of  a strike  that  could  have  an  impact  on  its  outcome.  There  are  a total  of 
10  input  variables.  Eight  of  the  variables  describe  the  numbers  of  specific 
Blue  and  Orange  force  units  that  will  operate  at  each  possible  launch  time. 

The  other  two  describe  the  weather  conditions  at  the  target  and  the  carrier 
at  each  possible  launch  time.  The  eight  unit-specific  input  variables  are 
grouped  for  display  and  data  entry  purposes  into  three  categories  — Blue 
Force  Readiness,  Orange  Air  Defenses  and  Orange  Ground  Forces.  Blue  Force 
Readiness  represents  the  numbers  of  three  types  of  Blue  aircraft  (one  fighter1 
and  two  attack  aircraft).  Orange  Air  Defenses  represents  the  numbers  of  two 
types  of  Orange  interceptor  aircraft.  Orange  Ground  Forces  describes  the 
numbers  of  two  types  of  Orange  defensive  system  (surface-to-air  missiles 
and  anti-aircraft  artillery  sites)  and  one  type  of  passive  ground  target. 

Each  input  force  unit  variable  is  described  by  a separate  probability  distribu- 
tion for  each  possible  launch  time,  while  the  weather  input  variables  are 
represented  simply  by  a probability  of  "good"  weather  at  each  possible  strike 
launch  time. 

The  output  variables  of  ASTDA  are  the  predictions  of  the  engagement 
model.  There  are  nine  output  variables,  the  number  lost  for  each  type  of 
Orange  or  Blue  system  involved,  and  the  composite  value  or  utility  score.  Each 
output  variable  is  represented  by  a probability  distribution  for  each  possible 
launch  time. 

The  principal  system  parameters  in  ASTDA  represent  fixed  factors 
from  which  the  segment- to-segment  survival  probabilities  are  computed.  They 
include: 

• The  one-on-one  survival  probabilities  for  each  possible 

pairing  of  engaging  forces,  r a \ 
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• The  proportion  of  total  units  of  a given  type  that  will  be 
deployed  against  each  type  of  opposing  unit, 

• The  number  of  sequential  engagements  that  can  occur  in  a single 
mission  segment  between  each  combination  of  engaging  units, 

• The  number  of  opposing  units  of  each  type  that  can  be  simul- 
taneously engaged  by  each  type  of  fighter  aircraft,  and 

• The  duration  (in  hours)  of  each  of  the  mission  segments. 

Parameters  in  the  first  four  groups  each  have  separate  values  for  good  and 
bad  weather.  All  of  these  parameters  are  inaccessible  to  the  user. 

2.1.5  Optimization  and  Analysis 

ASTDA  does  not  select  an  optimum  strike  time.  Instead,  it  computes 
and  presents  its  results  in  a way  such  that  the  decision  maker  can  readily 
select  an  optimum  strike  time  by  choosing  the  strike  time  with  the  highest 
expected  utility.  However,  since  some  decision  makers  may  desire  more 
detailed  information  than  is  provided  by  a single  summary  figure,  ASTDA 
provides  two  additional  analyses  — the  sensitivity  analysis  and  the  intra- 
process (or  loss-by-segment)  analysis. 

In  ASTDA,  each  input  variable  represents  a separate,  independent 
factor  which  has  a separate  and  distinct  effect  on  each  output  variable. 

ASTDA1 s sensitivity  analysis  enables  the  effects  of  variations  in  the  individual 
input  variables  on  the  output  variables  to  be  evaluated.  This  enables  the 
decision  maker  to  evaluate  the  effects  that  errors  in  the  estimation  of  the 
input  distributions  may  have  on  the  results  of  the  engagement.  When  using  a 
sensitivity  analysis  the  user  must  choose  a specific  strike  launch  time,  an 
input  variable  to  be  varied,  and  one  to  six  specific  values  of  the  input 
variable.  For  each  value  of  the  input  variable  ASTDA  runs  the  engagement 
model  at  the  specified  strike  time  using  the  same  value  of  the  input  variable 
each  time  the  model  is  run,  but  sampling  from  the  distributions  it  would 
otherwise  use  (for  that  strike  time)  for  all  the  other  input  variables.  This 
produces  distributions  of  results  for  each  output  variable  for  each  specified 
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value  of  the  input  variable  being  examined.  These  distributions  are  then 

* 

statistically  summarized  and  displayed  to  the  user  upon  request. 


The  intraprocess  analysis  allows  the  decision  maker  to  examine,  for 
a specific  strike  launch  time,  the  distributions  of  losses  for  both  the  Blue 
and  Orange  forces  in  each  segment  of  the  simulated  missions.  The  user  specifies 
a strike  launch  time,  and  ASTDA  runs  the  engagement  model  w.ith  the  data  for 
that  time,  recording  all  the  losses  in  each  segment  as  well  as  the  overall 
mission  losses.  It  then  displays  losses  in  each  segment  for  the  Orange  and 
Blue  forces. 
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2.1.6  Display  Features 

With  two  exceptions,  ASTDA  produces  simultaneous  tabular  and  color 
graphic  displays  of  the  same  information.  Each  display  shows  a group  of  , 
related  input  or  output  variables.  For  the  force  readiness  and  loss  data 
each  variable  in  a display  is  represented  by  an  uncertainty  band  defined  by 
three  statistics  of  the  distribution  — the  mean,  the  standard  deviation,  and 
a parameter  called  delta.  The  uncertainty  band  is  a two  standard  deviation 
range  around  the  mean  that  is  adjusted  to  most  nearly  equalize  the  portions 
of  the  distributions  above  and  below  the  endpoints  of  the  represented  range. 
The  amount  of  offset  or  bias  from  a symmetric  two  standard  deviation  range 
around  the  mean  is  called  delta.  In  tabular  representation,  an  uncertainty 
band  is  displayed  by  showing  the  mean  of  the  distribution  and  the  bounds  of 
the  uncertainty  band.  In  graphic  form,  the  uncertainty  band  is  drawn  as  a 
colored  bar  with  the  mean  indicated  by  a gap  in  the  bar.  For  the  displays 
of  weather  predictions,  the  probability  of  good  weather  at  each  relevant 
time  is  represented  as  a number  in  a table  or  a point  on  a graph. 


The  two  ASTDA  displays  which  have  no  graphic  form  are  those  which 
do  not  display  distribution  data  for  any  input  or  output  variables.  One  is 
the  display  of  the  weights  assigned  to  the  Blue  and  Orange  unit  types  by 
the  value  model.  The  other  is  a summary  display  of  the  times  at  which  all 
the  input  forecasts  were  entered  and  the  time  windows  covered  by  those 
forecasts. 
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Roles  of  Human  Judgment  and  Heuristics 

While  the  presentation  and  computation  of  utilities  for  each  of 
the  possible  strike  times  makes  available  to  the  decision  maker  a simple 
form  of  optimization  of  strike  time,  the  models  upon  which  the  utilities  are 
based  embody  a strong  set  of  assumptions.  Only  a highly  restricted  repre- 
sentation is  provided  for  the  context  of  the  air  strike  mission  and  the  con- 
text of  the  decision  situation.  Alternate  ways  to  evaluate  the  results  of 
the  engagement  model  are  not  addressed,  for  example,  in  terms  of  exchange 
ratios  or  relative  force  attrition.  The  additive  linear  value  function 
evaluates  the  strike  mission  results  by  considering  only  the  losses  sustained 
by  the  various  Blue  and  Orange  unit  types  without  regard  to  partial  damage  or 
initial  force  levels.  Also,  the  decision  maker  may  have  reason  to  have  more 
confidence  in  some  of  the  input  variable  predictions  than  in  others,  due  to 
personnel,  equipment  or  other  considerations,  and  he  must  somehow  deal  with  ' 
these  variations  in  confidence  in  his  interpretations  of  the  model  outputs. 

While  the  sensitivity  and  intraprocess  analysis  features  help  the  decision 
maker  to  include  exogeneous  variables  into  the  decision  process,  the 
identification  and  integration  of  these  factors  into  the  ASTDA  input  and 
output  information  is  left  to  his  judgment. 

The  displays  of  uncertainty  along  with  expected  values  enable  the 
user  of  ASTDA  to  consider  the  relative  risks  associated  with  the  strike  launch 
alternatives.  The  user  is  not  required  to  focus  only  on  the  expected  utility 
of  possible  actions.  Although  utility  functions  could,  in  principle,  be 
constructed  to  incorporate  the  risk  attitude  of  the  decision  maker,  the 
elicitation  of  the  relevant  judgments  for  such  constructions  can  be  a difficult, 
unreliable,  and  time  consuming  process.  By  displaying  statistical  uncertainty 
directly  to  the  decision  maker,  ASTDA  allows  him  to  make  explicit  considera- 
tion of  the  tradeoff  between  maximizing  expected  goal  achievement  and 
minimizing  the  risk  of  obtaining  unacceptable  results. 
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ROUTE  PLANNING  AID 

Integrated  Sciences  Corporation  (ISC)  has  investigated  the  use- 
fulness of  a variety  of  decision  aiding  concepts  for  the  problem  of  planning 
a transit  route  through  a field  of  enemy  radar  stations.  The  objective  of 
the  ISC  research  has  been  to  determine  the  best  way  to  allocate  problem 
solving  functions  between  the  human  and  the  computer.  Initial  work  focused 
on  evaluating  the  capability  of  the  human  to  draw  with  a graphics  input  device 
the  composite  detection  rate  function  of  several  radar  sensors  (Irving,  et  al . , 
1977).  A principal  conclusion  of  that  work  was  that  people  could  produce 
accurate  estimates  of  the  composite  detection  rate  function.  The  estimates 
of  detection  rate  functions  drawn  by  operators  were  called  Sketch  Models. 

A subsequent  investigation  (Walsh  and  Schecterman,  1978)  examined 
alternate  ways  to  formalize  the  route  planning  problem  and  various  degrees 
of  automation  that  could  be  used  in  search  for  an  optimal  transit  route.  The 
basic  route  planning  problem  in  all  cases  was  to  define  a path  in  terms  of 
connected  straight  line  segments  (called  path  legs)  with  a flying  speed  for 
each  leg.  The  goal  was  to  maximize  the  value  of  a nonlinear  utility  function 
which  depends  on  both  the  cumulative  probability  of  detection  and  the  quantity 
of  fuel  consumed  in  traversing  the  route.  Two  formalizations  of  the  problem 
were  considered.  In  one  representation,  all  decision  variables  were  treated 
as  discrete,  the  routes  being  constructed  by  connecting  adjacent  points  in 
a rectilinear  grid  and  the  flying  speed  for  the  legs  being  chosen  from  three 
distinct  values.  In  the  other  representation,  the  decision  variables  are 
continuous  with  the  routes  being  comprised  of  five  legs  with  connecting 
"waypoints"  located  anywhere  on  the  planning  map  and  flying  speeds  for  the 
legs  taking  any  values  between  maximum  and  minimum  limits.  For  each  type  of 
problem  representation,  three  general  types  of  decision  aiding  concepts  were 
developed  — manual  route  planning,  totally  automatic  route  planning,  and 
interactive  route  planning  (called  operator  aided  optimization,  or  0A0,  by 
ISC)  in  which  the  operator  directs  a constrained  automatic  search  procedure. 

A dynamic  programming  algorithm  was  used  for  the  automatic  and  0A0  search 
functions  for  the  discrete  version  of  the  problem  and  a nonlinear  programming 
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algorithm  performed  those  functions  for  the  continuous  version  of  the  problem. 
The  main  conclusions  of  the  study  were  that: 

• The  continuous  formulation  of  the  route  planning  problem  was 
more  appropriate  than  the  discrete  formulation. 

• The  OAO-NP  aiding  concept  ( i . e. , 0A0  with  nonlinear  programming) 
achieved  the  best  overall  problem  solving  performance. 

• The  lack  of  a technical  education  was  apparently  not  an  impedi- 
ment to  good  performance  with  or  without  either  type  of  aid. 

• The  time  required  to  train  an  operator  adequately  to  use 
either  aid  was  relatively  short,  namely,  four  hours. 

In  the  following  discussion  we  will  use  the  term  "Route  Planner"  to 
refer  to  the  manual  and  0A0  aiding  concepts  developed  by  ISC  to  address  the 
continuous  formulation  of  the  route  planning  problem.  In  the  manual  mode 
implemented  by  ISC  during  the  experiments,  the  operator  was  only  allowed  to 
make  a single  guess  at  the  best  route.  This  corresponds  to  the  unaided 
manner  in  which  route  planning  is  done  today;  it  served  as  a baseline  for 
comparison  with  the  0A0  concept  and  the  fully  automated  concept.  At  the  time 
of  this  writing,  ISC  is  about  to  start  an  experiment  to  compare  a modified 
version  of  manual  planning  with  0A0.  In  the  modified  version,  the  operator 
will  enter  a route  and  the  computer  will  calculate  and  display  criterion 
values  for  the  path,  including  cumulative  utility,  detection  probability,  and 
fuel  consumption.  The  operator  will  optimize  by  iteratively  seeking  improved 
paths  based  on  what  he  has  learned  from  criterion  values  obtained  from  pre- 
viously input  paths. 

The  OAO-NP  concept  developed  by  ISC  calls  for  the  operator  to  make 
an  initial  guess  at  the  best  route,  after  which  the  NP  algorithm  iteratively 
modifies  the  route  parameters  (path  geometry  and  flying  speeds)  to  achieve 
the  local  optimum.  In  general,  the  operator  must  try  several  cycles  of  the 
process  of  making  a guess  and  having  it  improved  by  the  NP  algorithm  before 
he  can  be  reasonably  assured  that  he  has  determined  a globally  optimal  path. 
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It  is  important  to  recognize  that  the  decision  aiding  concepts 
developed  by  ISC  to  assist  in  the  route  planning  have  been  oriented  more 
toward  addressing  general  issues  of  decision  aid  design  than  toward  the 
demonstration  of  a comprehensive  aid  for  an  operational  decision  problem. 

The  authors  of  the  ISC  documentation  cited  above  make  it  clear  that  an 
operational  route  planning  aid  would  have  to  incorporate  factors  (e.g., 
flight  altitude)  which  they  were  forced  to  reject  for  the  sake  of  experimental 
economy.  Nevertheless,  we  will  describe  the  Route  Planner  as  it  has  been 
configured  for  the  ISC  experiments  in  order  to  indicate  the  extent  to  which 
existing  software  can  be  borrowed  or  adapted  to  perform  route  planning 
functions  in  an  integrated  aid.  Figure  2-2  diagrams  the  structure  of  the 
Route  Planner. 

2.2.1  Target  Problem 

The  decision  aiding  concepts  developed  by  ISC  are  potentially 
applicable  to  a broad  range  of  multivariate  optimization  problems,  but  to 
date,  the  system  has  only  been  applied  to  the  problem  of  planning  a transit 
route  through  a dense  radar  surveillance  field..  The  current  system  requires 
an  input  file  that  specifies  the  origin  and  destination  of  the  route  and  the 
location  of  each  radar  station.  All  radar  stations  are  assumed  to  have 
identical  detection  capabilities  (though  in  the  earlier  research  with  the 
Sketch  Model,  variations  in  radar  detection  characteristics  were  implemented.) 
The  quality  of  a route  is  assumed  to  depend  on  the  cumulative  probability  of 
being  detected  and  the  expected  consumption  of  fuel,  though  other  criteria 
are  compatible  with  the  aid.  It  is  likely  that  the  route  planning  decision 
would  be  made  by  an  air  operations  officer.  The  appropriate  timeframe  for 
the  route  planning  decision  depends  on  the  availability  of  information  about 
the  locations  and  characteristics  of  enemy  radar  stations  and  their  capa- 
bility for  movement.  If  the  radar  stations  are  non-mobile  land-based  ' 
installations,  route  planning  may  be  conducted  days  or  weeks  in  advance  of^ 
the  transit  mission.  If  the  radars  are  ship-borne  or  mobile  land-based  units, 
the  route  planning  decisions  would  be  limited  to  several  hours  before  the 
start  of  the  mission.  For  airborne  radars,  it  would  probably  be  desirable  to 
have  a route  planning  aid  that  could  be  used  in  real  time. 
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Figure  2-2.  Route  Planner  Structure 
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2.2.2  Process  Model 

The  Route  Planner  has  no  engagement  model  comparable  to  those  used 
by  the  other  three  aids  described  here.  It  uses  closed  form  analytic  formulas 
to  model  the  consumption  of  fuel  and  the  cumulative  probability  of  being 
detected  as  aircraft  traverse  the  route  from  the  carrier  to  the  target.  Fuel 
consumption  is  computed  for  each  leg  in  the  route  by  multiplying  the  length  of 
the  leg  by  a fuel  consumption  factor  which  is  dependent  on  the  speed  chosen 
for  that  leg.  The  values  are  then  summed  across  all  the  legs  in  that  route. 

The  cumulative  probability  of  detection  is  also  computed  separately  for  each 
leg  and  then  combined  over  all  the  legs.  For  each  leg,  the  cumulative  prob- 
ability of  detection  is  computed  from  an  integral  of  the  detection  rate 
function  taken  over  the  interval  of  time  the  aircraft  is  traveling  the  leg. 

The  time  duration  of  a leg  is  calculated  directly  from  the  length  of  the  leg 
and  the  flying  speed.  Uncertainty  in  the  input  data  is  not  considered  in 
any  of  the  computations. 

2.2.3  Value  Model 

Two  attributes  for  the  value  of  a route  are  currently  identified 
in  the  Route  Planner,  cumulative  detection  probability  and  fuel  consumption 
over  the  approach  route.  In  addition  to  providing  the  user  with  separate 
information  about  these  component  route  criteria,  an  overall  route  utility 
is  defined  as  a nonlinear  function  of  both  criteria.  In  the  utility  function, 
a fuel  consumption  term  is  raised  to  a power  that  is  a function  of  the 
cumulative  probability  of  detection.  The  particular  form  of  the  utility 
function  is  somewhat  arbitrary,  with  a particularly  complicated  formula 
being  used  to  illustrate  the  versatility  of  the  technique  and  to  produce  a 
challenging  experimental  task  in  the  initial  judgment  of  an  approach  route. 

The  fuel  consumption  characteristics  of  the  strike  aircraft  are  explicit 
parameters  of  the  utility  function. 

2.2.4  Decision  Variables,  System  Variables,  and  System  Parameters 

The  decision  variables  in  the  route  planning  aid  are  the  features 
which  define  a candidate  route  — the  starting  and  ending  points  and  flying 
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speed  of  each  leg  of  the  route.  The  aid  defines  the  complete  route  as  con- 
sisting of  five  legs.  Since  the  starting  and  ending  points  of  the  complete 
route  are  predetermined,  four  points  remain  to  be  established  during  the 
decision  process  with  each  point  being  defined  by  two  coordinate  values. 

Flying  speeds  must  also  be  determined  for  each  of  the  five  legs  of  the  route. 
Consequently,  a total  of  13  decision  variables  are  treated  by  the  aid. 

Since  the  Route  Planner  has  not  yet  been  configured  for  operational 
use,  we  can  only  speculate  as  to  which  variables  will  be  accessible  to  the 
user  (i.e,  system  variables)  and  which  will  be  inaccessible  (i.e.,  system 
parameters).  It  seems  reasonable  to  expect  the  system  variables  to  include 
origin  and  destination  of  the  route,  sensor  locations  and  type  designations 
(assuming  that  more  than  one  type  of  sensor  will  be  considered).  The  Route 
Planner  automatically  calculates  and  displays  the  composite  detection  rate 
function  for  the  complete  field  of  radar  sensors.  The  output  variables  that 
are  available  to  the  user  for  each  route  are  the  utility  score  and  cumulative 
fuel  consumption  and  detection  probability  figures.  In  0A0  mode,  the  number 
of  iterations  of  the  optimization  algorithm  is  displayed.  System  parameters 
for  the  Route  Planner  presumably  include  the  specific  detection  capabilities 
for  the  radar  sensors  and  the  fuel  consumption  characteristics  of  the  air- 
craft flying  the  mission. 
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2.2.5  Optimization  and  Analysis 

In  0A0  mode,  the  Route  Planner  employs  a nonlinear  programming 
algorithm  to  determine  a local  optimum  for  the  utility  criterion  function 
by  using  the  user-supplied  candidate  route  as  a starting  point  and  varying 
the  starting/ending  points  of  the  legs  and  the  flying  speeds  on  them.  The 
terminal  points  of  the  legs  may  be  located  anywhere  on  the  planning  map  dis- 
played by  the  system.  The  search  is  iterative  so  that  a useful  result  can 
be  obtained  if  the  search  is  terminated  at  any  time.  The  particular  algorithm 
that  is  currently  implemented  uses  a gradient-free  method  that  does  not 
require  the  criterion  function  to  be  differentiable.  In  order  to  improve 
the  speed  of  the  search  for  a local  optimum,  Walsh  and  Schechterman  (1978) 
have  suggested  that  a gradient  search  method  be  developed. 
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In  OAO  mode,  a trace  of  the  "best  route  to  date"  can  be  retained 
on  the  graphic  map  display  along  with  its  various  value  criteria  while 
further  candidate  routes  are  formulated  and  evaluated.  No  special  analysis 
procedures  are  available  just  for  the  manual  mode. 

2.2.6  Display  Features 

The  Route  Planner  makes  extensive  use  of  color  graphic  display 
techniques.  The  operations  area  scenario  is  presented  in  the  form  of  a 
colored  map  with  the  composite  or  individual  sensor  detection  rate  functions 
displayed  as  iso-detection-rate  contours.  Different  colors  are  used  to 
code  different  detection  rates.  The  routes  are  entered  by  the  decision 
maker  through  an  interactive  graphics  method. 

2.2.7  Roles  of  Human  Judgment  and  Heuristics  ' 

Human  judgment  is  used  in  the  operator-aided  optimization  mode  to 

provide  the  nonlinear  programming  algorithm  with  a start  in  its  search  for 
a local  optimum  and  to  determine  when  the  search  should  be  stopped.  Humans 
are  able  to  process  the  information  contained  in  the  two-dimensional  display 
(really  a three-dimensional  display  projected  onto  two)  very  quickly  and 
intuitively.  The  human  operator  can  locate  likely  candidate  routes  by 
simply  examing  the  composite  detection  contours  or  even  the  overlapping 
individual  sensor  contours.  The  user  is,  in  all  likelihood,  applying  simple 
visually  based  problem  solving  heuristics  such  as  searching  for  the  "valleys" 
in  the  composite  detection  field,  or  by  seeking  an  "end  run"  around  the 
detection  field  to  one  side  or  another.  The  optimization  algorithm  is  unable 
to  selectively  choose  promising  starting  routes,  a task  at  which  the  human 
clearly  excels. 


2.3  EWAR 

The  Electronic  Warfare  aid  (EWAR)  developed  by  Decision-Science 
Associates  (Pugh,  Kerchner  et  al.,  1977;  Noble,  Pugh,  et  al.,  1978)  assists 
in  the  development  of  the  emission  control  (EMCON)  plans  for  a task  force. 

EWAR  facilitates  the  process  of  specifying  an  EMCON  plan  and,  once  one  has  been 
entered,  it  draws  upon  its  data  base  to  produce  estimates  of  the  surveillance 
coverage  the  plan  provides,  the  amount  of  information  the  plan  gives  away  to 
the  enemy  concerning  ship  identity,  and  the  portions  of  the  frequency  spectrum 
covered  by  the  plan.  If  the  user  specifies  potential  enemy  air  strikes 
against  the  task  force,  the  aid  will  use  a deterministic  engagement  model  to 
produce  estimates  of  the  effectiveness  of  the  surveillance  provided  by  the 
EMCON  plan  against  a strike  of  that  kind.  EWAR  also  allows  a comparison  of 
the  surveillance  effectiveness  and  the  amount  of  information  given  away 
across  several  candidate  EMCON  plans.  The  system  is  interactive  and  produces  ' 
both  tabular  and  graphic  displays.  The  structure  of  the  EWAR  aid  is  diagrammed 
in  Figure  2-3. 

2.3.1  Target  Problem 

EWAR  was  designed  to  aid  in  the  construction,  evaluation,  and  com- 
parison of  alternative  EMCON  plans  for  a carrier  task  force.  It  aids  in  the 
processing  and  coordination  of  a large  volume  of  information  on  sensor/plat- 
form capabilities  and  relationships  and  helps  to  balance  the  effectiveness 
of  surveillance  provided  by  the  EMCON  plan  against  the  amount  of  information 
concerning  the  task  force  provided  to  the  enemy.  The  effects  of  EMCON  plan- 
ning on  communication,  control,  and  sonar  surveillance  systems  are  not 
addressed  by  EWAR.  Three  roles  for  the  use  of  EWAR  can  be  distinguished  -- 
generation  of  EMCON  plans  to  be  incorporated  into  the  task  force  Op  Orders, 
modification  of  previously  specified  EMCON  plans  to  accommodate  changes  in 
task  force  disposition  or  equipment  status,  and  selection  of  an  EMCON  plan 
on  the  basis  of  estimates  of  enemy  plans  to  attack  the  task  force.  Thus,  a 
very  broad  range  of  timeframes  are  appropriate  for  the  use  of  EWAR.  For  all 
applications,  the  primary  user  of  EWAR  would  be  the  electronic  warfare  (EW) 
officer. 
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Figure  2-3.  EWAR  Structure 
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2.3.2 


Process  Model 

EWAR  incorporates  a variety  of  models  for  processes  associated 
with  task  force  defense  against  enemy  attacks.  These  include  a model  of  the 
enemy's  classification  of  task  force  ships  based  on  electromagnetic  emissions, 
several  models  for  the  enemy's  allocation  of  strike  aircraft  to  task  force 
ships,  a model  of  task  force  radar  system  performance  in  detecting  enemy  threats, 
and  a model  of  the  air  strike  engagement  between  enemy  aircraft  and  the  task 
force. 


It  is  assumed  that  the  enemy  uses  a Bayesian  inference  procedure 
to  classify  task  force  ships  on  the  basis  of  electromagnetic  emissions.  The 
inference  procedure  is  based  primarily  on  the  pattern  of  task  force  radar 
emissions  and  information  about  the  types  of  ships  in  the  task  force  and  the 
types  of  radars  carried  by  the  ships.  The  model  can  also  accommodate  user-  i 
specified  targeting  information  gained  from  other  intelligence  sources. 

Because  the  calculation  of  Bayesian  probabilities  requires  a prohibitive 
amount  of  computer  processing,  the  EWAR  algorithm  uses  an  approximation 
technique  which  gives  accurate  results  for  the  situations  of  concern. 

EWAR  allows  the  user  to  allocate  strike  aircraft  to  task  force 
ships  according  to  any  of  four  automatic  assignment  rules  or  by  manual  assign- 
ment. The  automatic  assignments  consist  of  allocating  strike  aircraft  to 
ships  either  optimally  or  proportionally  to  ship  value  where  ship  value  can 
be  based  on  either  the  actual  classification  of  the  ship  or  the  classification 
derived  from  the  Bayesian  inference  procedure.  Optimal  allocations  maximize 
expected  ship  damage.  They  consider  target  value,  optimal  attack  direction 
(within  specified  limits),  penetration  probability,  and  marginal  damage  for 
each  weapon. 

The  EWAR  model  for  the  performance  of  the  task  force  radar  system 
determines  the  detection  rate  for  a specified  aircraft  threat  by  all  operating 
task  force  radars.  The  model  considers  the  size  and  altitude  of  the  threat, 
its  distance  from  each  active  radar,  the  sea  state,  weather,  any  jamming  by 
the  enemy,  and  operator  detection  efficiency. 
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The  EWAR  model  for  the  strike  engagement  represents  the  engage- 
ment as  comprised  of  two  sequential  stages;  first  the  strike  aircraft  are 
engaged  by  task  force  air  defenses,  then  the  attacking  weapons  are  launched 
and  damage  is  inflicted  on  the  task  force  ships.  Both  processes  are  described 
probabilistically,  but  the  model  actually  operates  deterministically  with  the 
outcome  of  each  process  being  defined  as  taking  its  expected  value.  After  an 
approaching  strike  aircraft  is  detected,  a response  delay  (currently  90 
seconds)  must  occur  before  the  aircraft  can  be  engaged.  Thereafter,  the 
strike  aircraft  has  a 50  percent  chance  of  surviving  each  successive  125 
second  period.  Penetrating  weapons  have  a calculated  probability  of  hit  which 
is  different  for  each  weapon-ship  combination.  This  hit  probability  depends 
on  ship  length  and  parameters  which  indicate  the  accuracy  of  weapon  delivery. 
The  expected  damage  to  each  ship  depends  on  ship  hardness  (an  input  variable), 
quantity  of  weapons  carried  by  the  strike  aircraft  (also  an  input),  and  the  ' 
expected  number  of  hits.  EWAR  does  not  model  saturation  of  task  force 
defenses  by  large  numbers  of  attackers. 

2.3.3  Value  Model 

EWAR  provides  several  measures  that  can  be  used  for  comparing 
different  EMCON  plans.  These  measures  depend  on  user-assigned  ship  values. 

The  value  of  each  ship  represents  its  contribution  to  the  overall  task  force 
mission.  The  default  assignment  of  ship  value  is  in  proportion  to  the  ship's 
tonnage.  Three  different  types  of  value  score  used  in  EWAR  are  a surveillance 
score,  an  information  score,  and  a task  force  survival  score. 

The  surveillance  score  is  computed  as  the  weighted  average  of 
penetration  probabilities  for  three  standard  threats  attacking  the  task  force 
using  an  allocation  of  aircraft  to  ships  that  is  proportional  to  actual 
ship  value.  The  surveillance  score  considers  only  the  opportunity  for  a 
strike  force  to  launch  weapons  against  the  task  force,  not  the  damage  caused 
by  the  weapons. 


2-19 


The  information  score  is  a measure  of  information  denied  to  the 
enemy  by  a task  force  EMCON  plan.  It  is  computed  as  a multidimensional  geo- 
metric comparison  of  the  actual  value  of  each  ship  and  the  value  resulting 
from  the  way  the  enemy  (as  modeled)  classifies  the  ship  based  on  task  force 
radar  emissions  alone. 


The  task  force  survival  score  is  a measure  of  the  amount  of  initial 
task  force  value  that  would  survive  an  enemy  attack.  It  is  defined  on  the 
outputs  of  the  EWAR  strike  engagement  model.  The  engagement  model  determines 
the  fractional  damage  to  a ship  from  a given  attack.  The  survival  score  is 
computed  by  multiplying  the  value  of  each  ship  by  the  fractional  portion  of 
the  ship  that  survives  the  attack  and  then  summing  the  resultant  quantities 
over  all  ships  in  the  task  force.  It  is  a measure  of  surveillance  effective- 
ness, but  unlike  the  surveillance  score,  it  depends  on  the  specific  aircraft  , 
in  the  strike  force,  the  quantities  and  accuracies  of  weapons,  and  the  hard- 
ness of  task  force  ships.  The  survival  score  can  be  computed  for  strikes 
in  which  the  enemy  is  assumed  to  have  partial  or  complete  information  about 
the  classification  of  task  force  ships.  When  the  enemy  is  modeled  as  having 
partial  information,  the  survival  score  is  useful  in  analyzing  the  tradeoff 
between  denying  information  to  the  enemy  and  achieving  effective  surveillance. 
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2.3.4  Decision  Variables,  System  Variables,  and  System  Parameters 

The  problem  which  EWAR  helps  the  EW  officer  address  is  the  funda- 
mental structure  of  the  EMCON  plan  --  which  emitters  are  to  be  left  on  and 
which  are  to  be  turned  off.  Therefore,  there  is  no  single  simple  decision 
variable,  but  rather  a decision  matrix  of  emitters  and  ships. 


The  EWAR  system  parameters  which  are  outside  the  purview  of  the 
user  are  adjusted  by  the  system  designers  to  best  approximate  the  processes 
being  modeled.  These  parameters  include  task  force  response  time,  intercep- 
tion efficiency,  and  radar  operator  efficiency. 
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Some  system  variables  can  be  changed  by  the  user,  but  since  they 
represent  static  properties  of  force  resources  they  would  not  ordinarily 
be  changed  from  their  default  values.  Ship  hardness  belongs  in  this  category. 
It  represents  a physical  characteristic  of  a ship  (rather  than  a judgmental 
quality)  that  is  used  to  compute  ship  damage  from  specified  weapon  hits.  In 
the  experimental  data  base  currently  used  for  EWAR,  ship  hardness  is  derived 
from  ship  value.  When  EWAR  is  interfaced  with  a comprehensive  operational 
data  base,  ship  hardness  will  be  related  to  empirical  data  on  ship  vulnera- 
bilities. Other  static  system  variables  are  the  variables  that  describe  the 
performance  characteristics  of  enemy  strike  aircraft  and  weapons. 

Various  dynamic  system  variables  describe  the  particular  scenario 
for  EMCON  decision  making.  Such  variables  as  the  composition  and  approach 
direction  of  an  anticipated  strike  would  be  routinely  entered  and  adjusted 
by  the  EWAR  user  in  accordance  with  current  intelligence  estimates. 

2.3.5  Optimization  and  Analysis 

While  the  EWAR  aid  does  not  provide  for  direct  optimization  of  the 
on/off  assignments  in  the  EMCON  plan,  it  does  provide  a method  for  assessing 
the  tradeoffs  between  surveillance  effectiveness  and  information  given  away 
across  different  plans.  The  EWAR  engagement  model  computes  a surveillance 
effectiveness  score  for  an  EMCON  plan  across  a number  of  strike  threats,  and 
other  portions  of  the  aid  compute  an  information  given  away  value  score. 

These  two  scores  can  be  computed  and  saved  for  several  EMCON  plans  (using 
a coimon  strike  threat).  In  the  tradeoff  analysis,  these  pairs  of  scores  are 
displayed  for  up  to  ten  plans  simultaneously.  The  display  indicates  the 
relative  quality  of  each  of  the  plans  according  to  the  weights  assigned 
to  surveillance  effectiveness  and  information  given  away,  ranging  from  total 
consideration  given  to  one  criterion  to  total  consideration  given  to  the 
other.  This  feature  provides  the  decision  maker  with  a way  of  comparing  plans 
given  a judgment  about  the  relative  importance  of  the  two  ways  to  rate  the 
EMCON  plan. 
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Display  Features 

The  majority  of  EWAR  displays  are  in  a tabular  format  only,  listing 
information  on  sensors,  ships,  strikes,  aircraft,  etc.  There  are  also 
several  graphic  displays  that  fall  into  two  classes.  In  the  first  class 
are  the  displays  that  are  map-oriented,  showing  the  position  of  the  ships 
in  the  task  force  or  indicators  of  the  geographical  spread  of  the  radar 
surveillance  (either  individual  probability  of  detection  contours,  areas 
of  redundant  coverage,  or  combined  probability  of  detection  contours).  The 
second  class  includes  displays  in  the  form  of  bar  or  line  graphs  and  includes 
the  tradeoff  analysis  line  graph  and  the  bar  graph  showing  the  portions  of 
the  radar  frequency  spectrum  covered  by  an  EMCON  plan. 

2.3.7  Roles  of  Human  Judgment  and  Heuristics 

EWAR  draws  heavily  on  the  expertise  of  the  user  in  developing  and  i( 
analyzing  candidate  EMCON  plans.  Although  it  provides  no  direct  aid  in  the 
initial  construction  of  plans,  it  presents  various  types  of  information  that 
would  be  useful  in  the  development  of  variations  to  improve  a plan.  Initial 
candidate  plans  come  from  operations  manuals,  knowledge  of  standard  operations, 
or  a higher  command  level.  When  new  plans  are  being  developed,  there  are 
several  heuristics  which  may  guide  the  process,  notably  the  treatment  of  all 
emitters  of  a certain  type  in  a common  fashion  or  the  treatment  of  all 
emitters  on  a certain  ship  in  a common  fashion. 

EWAR  helps  the  decision  maker  consider  a tentative  plan  from  a 
variety  of  points  of  view  in  order  to  select  appropriate  analysis  options 
and  to  formulate  detailed  variations  that  might  improve  the  plan.  Displays 
that  help  the  user  focus  on  specific  characteristics  of  EMCON  plans  include 
the  combined  radar  coverage  display,  the  radar  frequency  range  coverage  dis- 
play, and  the  tabular  display  of  ships  that  can  be  mistaken  for  a given  ship 
under  a given  plan. 
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Since  the  aid  does  not  evaluate  EMCON  plans  on  a single  scale 
but  by  three  separate  measurements  (surveillance  effectiveness,  information 
given  away,  and  task  force  value  surviving),  the  judgment  of  the  decision 
maker  is  required  to  assess  the  relative  importance  of  each  type  of  rating. 
Additionally,  the  task  force  may  be  susceptible  to  several  different  types 
of  enemy  strikes  and  the  user  must  judge  the  importance  of  relative  effective- 
ness of  different  EMCON  plans  against  the  different  types  of  strikes.  Such 
judgments  are  facilitated  but  not  obviated  by  the  tradeoff  analysis  and  the 
displays  of  plan  characteristics. 


2.4  SOC 

The  Strike  Outcome  Calculator  (SOC)  developed  by  SRI  International 
(Rowney,  Garnero  and  Bobick,  1977;  Garnero,  Bobick  and  Ayers,  1978;  Garnero 
Rowney  and  Ketchell , 1978)  aids  the  operations  planner  in  estimating  the  con- 
sequences of  alternate  plans  for  a carrier-based  air  strike  campaign.  SOC 
requires  the  planner  to  formulate  a detailed  air  strike  campaign  plan  con- 
sisting of  mission  definitions,  target  assignments,  and  starting  and  stopping 
rules  for  contingent  missions.  It  interfaces  the  plan  with  a prestored  data 
base  to  create  inputs  to  a campaign  simulator  based  on  a deterministic  engage- 
ment model.  The  simulator  generates  campaign  outcome  predictions  in  the  form 
of  mission  accomplishment  statistics  and  overall  day-by-day  battle  losses. 

As  part  of  the  course-of-action  plan  for  the  campaign  simulator,  the  decision 
maker  also  supplies  a comprehensive  operation  plan  to  be  followed  by  the 
enemy.  The  SOC  can  be  run  either  interactively  or  in  a batch  mode.  It 
provides  tables  that  display  the  course-of-action  plan,  simulator,  output, 
and  background  and  scenario  data.  The  basic  structure  of  SOC  is  illustrated 
in  Figure  2-4. 
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starting  and  stopping  rules  for  contingent  or  interdependent  missions,  are 
formulated  by  the  user.  SOC  would  be  principally  used  du.’ing  the  early 
planning  phase  of  the  task  force  mission,  or  possibly  while  the  task  force 
is  enroute  to  the  area  of  conflict.  It  is  assumed  that  only  the  overall 
objective  of  the  campaign  has  been  specified  to  the  decision  maker  (e.g., 
to  destroy  enemy  air  capability  by  75  percent  in  20  days  or  less)  and  that, 
within  the  constraints  of  available  resources,  the  planner  has  considerable 
freedom  in  constructing  the  course-of-action  plans  to  meet  these  objectives. 

2.4.2  Process  Model 

SOC  employs  a highly  aggregated,  deterministic  campaign  simulator 
to  generate  estimates  of  the  results  of  a campaign  based  on  a stated  course- 
of-action  plan.  The  mission  simulator  permits  the  representation  of  operations 
of  Blue  (own)  force  against  Red  (enemy)  and  the  Red  operations  against  the 
Blue  task  force.  The  Red  force  has  the  capability  to  launch  offensive 
operations  against  the  Blue  task  force  as  well  as  defensive  operations  against 
incoming  Blue  strikes.  The  simulator  requires,  as  a result,  a course  of 
action  plan  to  be  created  by  the  decision  maker  for  Red  at  the  same  level  of 
detail  as  that  created  for  Blue.  The  campaign  is  simulated  on  a day-to-day 
basis,  with  each  day  broken  into  eight  three-hour  blocks.  Everything  that 
occurs  within  one  of  these  blocks  is  modeled  as  occurring  at  the  same  time. 

As  the  start  of  each  day,  the  simulator  examines  the  course-of-action  plans 
for  Red  and  Blue  and  schedules  the  missions,  subject  to  the  availability  of 
aircraft  and  launching  platform  capabilities,  for  each  three-hour  block  in 
the  day.  During  each  block,  the  simulator  recovers  airborne  aircraft  waiting 
to  land,  and  launches  the  scheduled  Blue  strikes  against  Red.  The  result 
of  each  strike  is  computed  by  a three-stage  engagement  model.  The  model  first 
/ considers  the  engagement  between  the  incoming  strike  force  and  interceptor 

{ aircraft,  then  the  engagements  between  the  strike  force  and  ground  defenses, 

* and  finally  between  the  strike  force  and  the  ground  targets.  Each  of  these 

I f engagements  is  modeled  simply  by  multiplying  exchange  rate  values  by  the 

sizes  of  the  engaging  forces  on  each  side.  After  all  the  Blue  strikes  in 


the  block  have  been  launched,  all  the  Red  strikes  against  Blue  are  launched. 

At  the  end  of  each  simulated  day,  the  loss  and  mission  accomplishment  sta- 
tistics for  both  sides  are  recorded.  This  process  is  repeated  for  each  day 
of  the  campaign. 

2.4.3  Value  Model 

Unlike  the  ASTDA,  EWAR,  and  Route  Planner  aids,  SOC  makes  no  use 
of  an  explicit  value  model  to  aggregate  or  evaluate  the  results  of  the  simulated 
campaign.  However,  the  particular  types  of  results  that  are  presented  in  the 
SOC  output  tables  constitute  criteria  for  judging  the  value  of  a campaign.  In 
particular,  the  SOC  outputs  enable  the  decision  maker  to  observe  when  and 
with  what  aircraft  complement  each  contingent  mission  is  implemented  in  the 
simulation  and  how  many  units  of  each  type  are  destroyed  at  each  force  complex 
and  on  each  day  of  the  campaign.  Implicit  judgments  of  value  are  also  required 
in  the  establishment  of  several  SOC  inputs  such  as  mission  priorities  and 
target  assignments. 

2.4.4  Decision  Variables,  System  Variables,  and  System  Parameters 

The  decision  variables  in  SOC  are  the  features  of  the  Blue  operations 
plan.  The  plan  consists  of  one  or  more  missions,  each  of  which  must  be 
assigned  a priority,  an  origin,  a destination,  starting  and  stopping  rules 
(events  on  which  the  start  and  termination  of  the  mission  are  contingent), 
times  of  launch  in  each  day,  and  the  type  and  number  of  units  desired  for 
the  mission. 

While  SOC  makes  nearly  all  of  its  data  accessible  for  the  user  for 
display  or  modification  purposes,  there  is  a distinction  between  those  data 
that  are  intended  to  be  estimated  by  the  user  and  those  that  are  intended 
to  be  obtained  from  external  sources.  The  former  data  types  will  be  con- 
sidered input  variables , the  latter  parameters. 

The  SOC  input  variables  include  the  definitions  of  the  elements 
(aircraft,  target,  and  defensive  system  types),  units  (strike  complements  of 
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different  aircraft  elements),  and  complexes  (major  clusters  of  resources, 
such  as  a carrier  task  force,  airfield,  or  supply  line)  for  both  the  Red 
and  the  Blue  forces.  The  Red  operations  plan,  which  is  required  by  the 
campaign  simulator,  is  another  input  variable.  It  is  not  a decision  variable 
as  is  the  Blue  operations  plan,  because  the  decision  maker  obviously  has  no 
power  to  decide  on  the  defensive  strategy  Red  will  use,  even  though  he  must 
estimate  it  in  order  to  obtain  outputs.  Two  final  input  variables  are  the 
day-by-day  prediction  of  weather  in  the  operations  area  and  the  assignment 
of  distances  (either  "long"  or  "short")  between  the  Red  and  Blue  complexes. 
Weather  is  considered  to  be  either  "good"  or  "bad"  and  constant  within  each 
single  day  of  the  campaign.  No  estimation  of  uncertainty  is  represented  for 
any  of  the  input  variables. 

The  SOC  output  variables  are  the  campaign  results  produced  by  the  ' 
campaign  simulator.  There  are  three  types  of  output  variables  --  mission 
accomplishment  results,  battle  attrition  results,  and  aircraft  expenditures. 
Mission  accomplishment  results  indicate,  for  each  mission  in  both  the  Red 
and  Blue  operations  plans,  the  actual  days  on  which  the  mission  was  begun 
and  ended  and  the  number  of  units  launched  and  engaged  by  the  opposing  sides 
in  fulfilling  the  mission.  Battle  attrition  results  list,  for  each  Red  and 
Blue  complex,  the  number  of  each  type  of  element  lost  and  the  original  number 
of  that  type.  The  loss  figures  do  not  include  damaged  elements  although 
damage  is  represented  in  the  campaign  simulation.  Aircraft  expenditure 
reports  describe  the  number  of  sorties  flown  by  each  type  of  Blue  and  Red 
aircraft  and  the  number  lost  to  air-to-air  and  air-to-ground  engagements  for 
each  day  of  the  campaign.  As  with  the  input  variables,  there  is  no  treat- 
ment of  uncertainty  in  any  of  the  output  variables. 

SOC  parameters  reflect  the  capabilities  of  various  elements  or 
complexes  in  the  scenario.  Some  parameters  represent  weapon  platform  availa- 
bility statistics  (normal  and  surge  sortie  rates  and  replenishment/refuel 
time  required),  and  repair  and  launch  capabilities  of  the  complexes.  The 
engagement  statistics  or  exchange  rate  tables  which  are  used  by  the  campaign 
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simulator  engagement  model  constitute  another  set  of  parameters.  The  engage- 
ment statistics  are  framed  in  terms  of  losses  to  defending  elements  and 
attacking  units  expected  from  a single  engagement.  Finally,  a number  of 
campaign  duration  and  strategy  parameters,  such  as  maximum  number  of  days  in 
the  battle  and  length  of  time  for  various  types  of  missions,  must  be  set  by 
the  SOC  user  before  the  simulator  can  be  run. 

2.4.5  Optimization  and  Analysis 

SOC  provides  no  explicit  optimization  features,  but  it  does  con- 
tain some  capabilities  which  enhance  the  comparison  of  alternative  operations 
plans.  The  load/store  features  of  SOC  allow  the  user  to  establish  and  store 
several  alternative  course-of-action  plans,  and  then  reload  and  simulate 
each  to  compare  the  campaign  results  generated  by  the  simulator  using  each 
different  plan.  The  priority  assignment  for  missions  allows  different  forms  ' 
of  missions  to  be  compared  easily.  Each  mission  must  be  assigned  a priority, 
but  missions  with  a priority  of  zero  will  never  be  launched.  The  decision 
maker  can,  therefore,  enter  several  alternative  specifications  for  a mission 
into  the  operations  plan  and  sequentially  test  their  impact  on  the  campaign 
results  by  giving  the  alternative  being  tested  a non-zero  priority  and  all 
the  others  a zero  priority. 

2.4.6  Display  Features 

Although  only  tabular  displays  are  used  in  SOC,  it  can  only  be 
run  on  certain  types  of  character  display  terminals.  SOC  makes  available 
to  the  user  all  of  the  input  variables,  parameters,  and  outcome  variables 
through  a set  of  19  tables.  Each  of  these  can  be  viewed  independently  by 
the  user,  although  when  a totally  new  problem  is  being  entered,  the  tables 
must  be  called  and  loaded  in  their  numerical  sequence.  Update  of  existing 
values  or  entry  of  new  values  in  a table  is  done  by  positioning  a cursor  to 
the  location  of  the  data  in  the  table  and  simply  entering  it,  overwriting 
whatever  (if  anything)  was  there. 
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2.4.7 


Roles  of  Human  Judgment  and  Heuristics 

The  judgment  of  the  decision  maker  is  crucial  in  SOC  by  virtue 
of  the  absence  of  optimization,  sophisticated  analysis  features,  or  an  explicit 
value  model.  While  the  aid  determines  the  form  of  a course-of-action  plan,  it 
leaves  the  specification  of  the  plan  for  both  Blue  and  Red  to  the  user,  who 
must  rely  on  his  training  and  experience.  In  this  sense,  SOC  is  more  of  a 
tool  for  assessing  the  consequences  of  a camapign  plan  than  an  aid  for  con- 
structing one.  The  evaluation  of  the  overall  campaign  results  produced  by 
the  campaign  simulator  is  also  relegated  to  the  judgment  of  the  user,  since 
no  value  scale  for  combining  the  various  outputs  is  provided  by  the  aid. 
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3.  GENERAL  ISSUES  FOR  INTEGRATION 


3.1  TARGET  PROBLEMS 

There  are  a variety  of  issues  that  must  be  addressed  in  designing 
a system  that  integrates  a set  of  decision  aids.  The  first  is  the  determina- 
tion of  the  range  of  decision  problems  for  which  the  system  is  to  be  used. 
Primary  candidate  problems  for  the  integrated  system  are  all  the  problems  that 
are  addressed  by  the  separate  component  aids.  It  is  also  possible  that  the 
integrated  system  will  be  able  to  deal  with  some  variations,  extensions,  and 
combinations  of  these  basic  problems  by  exploiting  some  of  the  complementary 
characteristics  of  the  component  aids.  In  addition,  new  problem  applications 
may  be  possible  by  incorporating  elaborations  on  the  component  software  in 
the  integrated  system.  The  ultimate  choice  of  the  additional  decision  problems 
to  be  addressed  by  an  integrated  system  will  be  dependent  largely  on  the  cost 
of  dealing  with  additional  problems  and  on  the  probable  usefulness  of  the 
additional  capabilities. 

The  aids,  as  currently  implemented,  deal  with  the  problems  of  plan- 
ning a task  force  campaign  and  of  emission  control  policies  for  that  campaign, 
as  well  as  the  more  action-oriented  problems  of  determining  an  approach  route 
and  a launch  time  for  a single  air  strike.  Through  a variety  of  extensions, 
modifications,  and  different  combinations  of  the  four  current  decision  aids, 
many  additional  types  of  decision  problems  could  be  addressed.  Some  of  the 
possibilities  are: 

• The  ASTDA  engagement  model  could  be  used  to  address  aspects 
of  the  strike  planning  problem  other  than  launch  time,  such 
as  ideal  strike  force  complement,  allocation  of  attack  air- 
craft to  ground  defenses  and  targets,  and  consequences  of 
various  mission  abort  rules. 
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• ASTDA  and  SOC  components  could  be  combined  to  deal  with  short 
sequences  of  interdependent  strike  decisions  in  the  same 
operational  timeframe  as  ASTDA.  One  such  problem  is  the 
choice  of  launch  times  for  two  strikes  on  the  same  day. 

li 

• The  Route  Planner  could  be  integrated  with  EWAR  to  help  the 
user  determine  the  relative  vulnerability  of  the  task  force 
to  enemy  strikes  using  different  approach  routes. 

• EWAR  could  be  modified  for  application  to  the  operational 
problems  of  determining  which  EMCON  plan  to  use  in  a specific 
situation. 

• SOC  and  EWAR  could  be  used  together  to  develop  campaign  plans 
that  include  specifications  of  contingencies  for  applying 
various  EMCON  plans. 

Although  it  is  possible  to  use  the  current,  separate  versions  of 

I 

the  ODA  decision  aids  to  attack  these  new  problems,  such  attempts  would 
probably  be  frustrated  by  a variety  of  limitations  in  each  aid  and  by  incom- 
patibilities between  the  aids. 

It  is  therefore  important  to  define  the  full  range  of  problems  for 
which  the  new  integrated  system  is  to  offer  assistance  before  the  system  is 
developed.  A complete  statement  of  objectives  will  permit  identification  of 
possible  undesirable  gaps  in  system  applications.  It  would  also  permit  the 
consideration  of  marginal  cost-benefit  issues  concerning  the  development 
costs  required  to  enable  the  system  to  deal  with  new  problems. 

3.2  PROCESS  MODELS 

A second  integration  issue  relates  to  the  nature  of  the  processes 
described  by  the  aids  and  the  way  in  which  those  processes  are  modeled.  Three 
of  the  four  decision  aids  being  considered  — SOC,  EWAR,  and  ASTDA  --  incorporate 
some  type  of  mathematical  model  of  the  air  strike  engagement.  The  engagement 
models,  however,  are  all  distinctly  different  from  one  another.  Although  all 
the  models  ostensibly  represent  the  same  type  of  air  strike  scenario  and 


i i although  they  employ  comparable  levels  of  detail  for  input  and  output  variables, 

the  processes  are  described  in  different  ways  with  different  variables  in  each 
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aid.  These  differences  are  partly  the  result  of  differences  in  orientation 

among  the  decision  aids  and  partly  the  result  of  differences  in  the  aid 

developers'  concepts  of  the  engagement  process.  The  particular  forms  of 

the  engagement  models  were  generally  secondary  considerations  in  decision 
aid  development  with  all  the  aid  developers.  Their  primary  objectives  were 
to  demonstrate  the  value  of  particular  decision  aiding  techniques  and  the 
value  of  particular  kinds  of  information  in  particular  kinds  of  problems. 

We  do  not  want  these  statements  to  be  construed  as  casting  blame  or  finding 
fault  with  any  individual's  or  organization's  work.  We  are  simply  stating 
that  the  development  efforts  were  not  oriented  toward  the  development  of  the 
ultimate  engagement  model.  Process  models  were  needed  so  that  the  desired 
output  data  could  be  generated  from  the  available  input  data  for  each  of 
the  aids,  but  it  was  not  considered  necessary  to  develop  the  best  possible 
models  for  the  exploratory  study  of  the  aiding  techniques.  Fairly  crude 
process  models  were  felt  to  be  capable  of  generating  sufficiently  reasonable 
outputs  for  the  initial  evaluations  of  decision  aid  concepts.  Operationally 
acceptable  models  requiring  substantial  development  costs  were  justifiable 
only  when  it  was  clear  that  the  resulting  aid  would  be  acceptable  to  the  user 
population  and  enjoy  extensive  use. 

All  three  of  the  engagement  models  describe  attrition  of  force 
elements  as  a function  of  the  numbers  of  all  types  of  elements  involved  in 
the  engagement.  The  ASTDA  model  represents  a carrier-launched  air  strike 
against  a defended  ground  target.  It  is  the  most  elaborate  of  the  three 
models  because  it  attempts  to  describe  the  complete  distribution  of  possible 
results  associated  with  specific  engagement  conditions.  The  other  two 
models  describe  only  the  average  results  that  should  be  expected  for  any 
engagement.  The  EWAR  model  is  concerned  only  with  air  strikes  against  a 
naval  task  force  in  the  open  sea,  while  the  SOC  model  represents  air  strikes 
against  both  land  and  sea  targets.  The  three  models  use  different  parameters 
from  one  another  to  describe  the  capabilities  of  force  elements  to  inflict 
damage  on  enemy  force  elements  and  resources.  The  ASTDA  model  distinguishes 
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only  between  survival  and  loss  of  force  elements  while  the  SOC  and  EWAR 
models  distinguish  degrees  of  damage  to  force  elements. 


Although  it  would  be  desirable  for  an  engagement  model  to  use  only 
observable,  quantifiable  data  for  inputs  and  model  parameters,  the  engagement 
models  in  ASTDA,  EWAR  and  SOC  all  require  a variety  of  subjective  estimates 
of  the  fighting  capabilities  of  aircraft  and  ground  defense  elements.  Some- 
what different  engagement  capability  estimates  are  required  by  the  three 
models.  ASTDA  asks  the  user  to  estimate  the  probability  that  each  adversary 
will  survive  in  a specified  one-on-one  engagement.  SOC  asks  the  user  to 
estimate  the  probability  that  each  aircraft  of  one  adversary  will  survive  in 
an  engagement  with  a standard  grouping  of  the  other  adversary's  aircraft. 

EWAR  asks  the  user  to  estimate  the  capability  of  each  task  force  vessel  to 
survive  enemy  ordnance,  i.e.,  the  "hardness"  of  the  ship. 

One  way  to  resolve  the  differences  between  the  engagement  models  in 
the  integrated  aid  is  to  develop  a single  engagement  model  that  satisfies 
the  requirements  of  all  the  decision  aids.  Such  a model  could  be  developed 
from  the  three  existing  models  and  could  be  designed  to  incorporate  the 
important  features  of  each  model . Some  of  the  necessary  features  of  such  a 
combined  model  would  be  that  it  would: 

• Describe  damage  to  force  elements  as  well  as  survivals  and 
losses. 

• Be  sensitive  to  weather  conditions. 

t Be  exercised  in  either  a stochastic  mode  to  predict  the  com- 

plete distribution  of  engagement  results  or  in  a deterministic 
mode  to  predict  average  expected  results. 

• Be  sensitive  to  the  times  when  information  about  opposing 
force  locations  and  motions  were  available  to  each  adversary. 

• Structure  the  engagement  process  in  terms  of  sequential  segments 
representing  approach  of  strike  force  to  target,  engagement 
between  strike  force  and  interceptor  force,  engagement  between 
strike  force  and  ground  defenses  and  targets,  and  return  of 
strike  force  to  base  of  origin. 

• Represent  strikes  against  both  land  and  sea  forces. 
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Although  the  Route  Planner  does  not  currently  incorporate  any  engage- 
ment model,  it  is  noteworthy  that  the  combined  model  described  above  could  be 
advantageously  used  in  conjunction  with  the  Route  Planner.  Basically,  a 
deterministic  engagement  model  together  with  a value  function  for  engagement 
results  could  be  used  in  place  of  the  utility  function  currently  used  in  the 
Route  Planner.  The  current  Route  Planner  evaluates  a candidate  route  according 
to  the  fuel  consumed  in  traversing  it  and  the  probability  that  a strike  force 
that  flies  the  route  will  be  detected  by  the  enemy.  The  route  planning  function 
in  the  integrated  aid,  on  the  other  hand,  would  evaluate  candidate  routes  in 
terms  of  the  expected  results  of  engagements  initiated  by  those  routes.  In 
the  former  case,  the  impact  on  mission  achievement  of  fuel  consumption  and 
detection  by  the  enemy  would  be  estimated  by  a speculative  value  model,  while 
in  the  latter  case  the  impact  of  the  same  variables  would  be  estimated  at  least 
partly  by  a model  of  the  implemented  mission. 


As  in  the  development  of  the  individual  decision  aids,  the  particular 
form  of  the  engagement  model  in  the  integrated  aid  will  be  a relatively  minor 
concern  during  initial  aid  development.  The  principal  role  of  the  engagement 
model  will  be  to  define  the  specific  variables  that  are  to  be  functionally 
related  by  the  model.  A plausible  model  will  be  required  to  enable  demonstra- 
tions and  experiments  to  be  performed  to  provide  data  and  judgments  for  the 
guidance  of  further  aid  development,  but  it  will  not  be  necessary  for  the  model 
to  be  validated  against  empirical  criteria  until  a later  stage  of  development. 
Only  when  the  data  requirements  of  the  integrated  decision  aid  are  firmly 
established  will  it  be  appropriate  to  devote  an  intensive  effort  to  the 
development  of  the  engagement  model.  As  the  integrated  aid  is  developed,  we 
should  expect  some  fluctuations  in  the  demands  made  on  the  engagement  model, 
both  in  terms  of  the  specific  variables  to  be  interrelated  and  in  the  levels  of 
detail  with  which  they  are  treated.  But  at  all  stages  of  development,  some 
engagement  model  will  be  required  to  permit  diagnostic  exercising  of  the  system. 


3.3  VALUE  MODELS 


A value  model  is,  in  general,  a mechanism  for  quantifying  an 
individual's  satisfaction  or  pleasure  in  encountering  a particular 
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situation.  For  the  command  and  control  decisions  of  a naval  task  force,  how- 
ever, it  is  not  so  much  the  individual  decision  maker  as  the  higher  authorities 
who  established  the  objectives  for  the  task  force  who  must  be  satisfied.  Thus, 
in  the  present  context,  a value  model  constitutes  a tool  for  measuring  the 
extent  to  which  a situation  represents  achievement  of  a set  of  objectives  or 
the  extent  to  which  the  situation  facilitates  the  achievement  of  those  objec- 
tives. ASTDA  and  EWAR  employ  value  models  to  estimate  how  well  the  results  of 
strike  missions  satisfy  task  force  objectives.  The  Route  Planner  uses  a value 
model  to  measure  the  degree  to  which  a strike  route  facilitates  an  effective 
strike  mission. 

In  all  of  these  cases,  values  are  measures  of  movements  toward  or 
away  from  ultimate  goals.  But  it  is  usually  difficult  to  judge  the  impact  of 
immediate  events  on  long-term  goals,  so  short-term  goals  associated  with  the 
immediate  situation  are  identified  and  used  as  surrogates  for  the  long-term 
goals.  Rather  than  to  attempt  to  weigh  the  possible  results  of  an  air  strike 
in  terms  of  a detailed  analysis  of  the  relationship  of  those  results  to  task 
force  objectives,  it  is  much  more  expedient  and  reliable  to  use  a simple  value 
function  based  on  the  force  attrition  to  both  adversaries  involved  in  the  strike 
engagement.  It  is  even  more  expedient  to  assign  values  to  the  initial  condi- 
tions of  a strike  engagement  and  thereby  avoid  the  complexity  of  an  engagement 
model,  as  is  done  in  the  Route  Planner.  However,  the  further  removed  the  value 
model  is  from  the  variables  that  describe  the  ultimate  mission  objective,  the 
more  difficult  it  is  to  ensure  that  the  value  model  is  completely  consistent 
with  those  objectives. 


These  two  observations  about  value  models,  that  values  measure  achieve- 
ment of  objectives  and  that  value  functions  are  often  defined  on  intermediate, 
surrogate  objectives  rather  than  on  long-term  objectives,  are  important  considera- 
tions when  consolidating  component  value  models.  In  an  integrated  aid,  all 
valuations  should  relate  to  the  same  long-term  objectives.  Value  assignments 
to  short-term  objectives  should  be  made  consistently  and  with  reference  to 
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the  long-term  objectives.  Values  assigned  to  different  short-term  objectives 
should  reflect  the  relative  contribution  of  the  surrogate  objectives  to  the 
long-term  goals.  Consequently,  an  integrated  aid  should  use  a single  scale 
of  value  measurement.  The  three  value  models  from  EWAR,  ASTDA,  and  the  Route 
Planner  can  be  consolidated  fairly  easily  since  they  all  deal  with  the  same 
surrogate  parameter  — force  attrition  in  a single  air  strike.  (The  Route 
Planner  can  define  values  in  terms  of  strike  mission  results  in  the  manner 
described  in  Section  3.2  by  using  an  engagement  model.)  However,  a value  model 
for  long-term  task  force  missions  that  is  consistent  with  both  the  true  long- 
term objectives  and  the  short-term  value  model  is  more  problematical.  A 
simple  force  unit  attrition  function  may  not  be  an  adequate  way  to  represent 
long-term  task  force  goals.  For  example,  the  objective  of  the  task  force  may 
be  to  neutralize  an  air  strike  campaign  waged  by  one  third  world  nation  against 
another,  but  with  the  stipulation  that  minimal  damage  is  to  be  inflicted  by 
the  task  force  in  order  to  avoid  aggrevating  a sensitive  political  situation. 

An  appropriate  value  model  for  this  objective  would  discriminate  factors  other 
than  massive  destruction  that  would  lead  to  the  termination  of  the  air  strike 
campaign.  It  would  also  deal  in  a complex  way  with  enemy  force  attrition. 

Such  a value  model  of  long-term  goals  would  in  turn  raise  doubts  about  the 
validity  of  a value  model  for  short-term  goals  that  dealt  only  with  force 
attrition  data  in  single  strike  engagements. 

This  difficulty  is  not  peculiar  to  task  force  campaign  planning.  In 
fact,  it  is  generally  the  rule  rather  than  the  exception  that  human  decision 
makers  are  ambiguous  about  how  they  move  toward  global  goals  when  making  deci- 
sions in  contextually  restricted  situations.  As  March  (1978)  points  out,  it 
is  often  quite  intelligent  to  behave  in  this  way.  It  is  often  unclear  to  the 
decision  maker  how  the  outcome  of  the  present  decision  situation  will  contribute 
to  the  achievement  of  global  objectives,  particularly  when  many  subsequent 
decisions  and  uncertain  events  lie  between  the  immediate  outcome  and  the  global 
objective.  Furthermore,  the  contextual  boundaries  of  the  "local"  decision 
often  impose  a restricted  rationality  on  the  situation  that  prevents  the  deci- 
sion at  hand  from  being  maximized  on  the  global  and  local  value  functions 
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simultaneously.  The  hypothetical  limited  warfare  situation  posed  in  the 
above  paragraph  is  representative  of  this  type  of  conflict  between  the  bounded 
rationality  of  a limited  decision  situation  (i.e.,  how  to  neutralize  the 
aggressor  nation's  air  campaign),  which  dictates  maximizing  the  damage 
inflicted  as  the  surest  way  to  achieve  the  local  goal,  and  the  global  objec- 
tive (i.e.,  defusing  a tense  political  situation)  which  dictates  an  opposite 
decision  criterion  of  minimizing  the  damage.  Even  disregarding  March's 
concern  with  the  transience  of  preferences  and  its  role  in  exacerbating 
decision  makers1  tendency  ^oward  global  value  function  ambiguity  (since  in 
military  situations,  preferences  can  be  considered  to  be  externally  imposed 
by  higher  command  levels),  the  rationality  of  being  ambiguous  about  global 
tastes  is  a majqr  problem  to  be  dealt  with  in  constructing  a value  model  for 
an  integrated  aid. 

One  possible  way  to  solve  this  problem  has  been  suggested  by  Pearl 
(1977).  He  argued  that  value  models  for  short-term  goals  should  be  defined 
in  terms  of  conditional  probabilities  for  the  achievement  of  the  long-term 
goal.  That  is,  the  value  of  any  possible  immediate  situation  should  be 
defined  as  the  conditional  probability  that  the  long-term  goal  will  eventually 
be  achieved  given  that  the  possible  situation  actually  occurs.  With  a com- 
prehensive simulator  of  the  campaign  process,  e.g.,  SOC,  it  is  conceivable 
that  sensitivities  of  long-term  objectives  to  the  results  of  single  strike 
engagements  could  be  systematically  analyzed.  A key  component  that  is  miss- 
ing for  this  approach  is  a value  model  for  the  overall  campaign  objectives. 

It  may  be  the  difficulty  of  the  task  of  developing  such  a model  that  accounts 
for  the  fact  that  the  SOC  is  the  only  aid  of  the  four  considered  here  that 
does  not  incorporate  a value  model.  Although  it  may  seem  plausible  that  the 
outcome  of  a single  strike  engagement  could  be  accurately  valued  in  terms  of 
a linear  additive  function  of  constituent  force  attrition,  it  is  much  more 
difficult  to  accept  that  the  final  result  of  an  extended  task  force  campaign 
might  be  evaluated  as  a weighted  sum  of  accumulated  force  losses  or  survivals. 
The  objectives  of  task  force  campaigns  cannot  necessarily  be  defined  in  terms 
of  an  ideal  level  of  destruction  to  be  inflicted  on  the  enemy  and  a maximum 


permissilbe  level  of  damage  to  be  incurred  by  the  task  force.  Other  factors, 
such  as  preventing  the  enemy  forces  from  indulging  in  other  activities  at 
specific  times,  may  be  major  considerations  in  task  force  objectives.  Con- 
sidering the  difficulty  of  quantifying  long-term  task  force  objectives,  it  is 
appropriate  to  expect  descriptions  of  force  attrition  and  combat  events  to 
be  the  primary  outputs  of  a campaign  planning  aid  and  an  aggregated  value 
model  to  be  an  optional,  secondary  output. 

3.4  DECISION  VARIABLES,  SYSTEM  VARIABLES,  AND  SYSTEM  PARAMETERS 

The  particular  variables  to  be  treated  as  decision  variables  in  an 
integrated  system  are  dependent  upon  target  problems  to  be  dealt  with  by  the 
integrated  aid.  Ideally,  the  system  should  be  designed  in  such  a way  that 
virtually  any  variable  may  be  treated  as  a decision  variable  and  subjected 
to  the  analyses  and  optimizations  warranted  by  its  role  in  the  analysis. 

Such  a design  would  enable  new  model  features  for  the  treatment  of  new 
target  problems  to  be  easily  accommodated  and  would  ensure  that  the  aid 
could  be  applied  to  the  maximum  number  of  different  problems. 


In  an  integrated  system,  the  distinction  between  the  terms  "system 
variables"  and  "system  parameters"  as  used  in  the  discussion  of  decision  aids 
in  Section  2 would  be  less  clear.  System  variables  referred  to  variables  to 
which  the  aid  user  had  fairly  free  access;  system  parameters  referred  to  the 
less  accessible  variables.  In  the  integrated  system,  all  variables  involved 
in  the  component  process  and  value  models  will  be  accessible  to  the  user, 
i.e.,  will  be  system  variables.  A data  structure  that  would  support  this 
flexibility  is  described  in  Section  5.  In  this  structure,  data  would  be 
segregated  on  the  basis  of  permanence.  A background  data  base  would  contain 
information,  like  the  performance  characteristics  of  weapons  and  sensor  plat- 
forms, that  could  be  expected  to  remain  constant  over  the  course  of  a campaign. 
A scenario  data  base  would  contain  transistory  information,  like  force  loca- 
tions and  movements,  that  must  be  supplied  at  the  time  of  any  specific 
decision.  The  user  will  be  able  to  review  and  update  all  information  in  both 
data  bases,  but  according  to  somewhat  different  procedures. 
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A number  of  new  variables,  not  currently  treated  by  any  of  the  four 
separate  decision  aids,  would  have  to  be  incorporated  in  the  integrated 
system.  For  the  sake  of  expedience  in  developing  the  demonstration  systems, 
some  potentially  relevant  variables  were  excluded  from  the  component  process 
and  value  models.  However,  as  the  systems  move  toward  an  operational  con- 
figuration, it  is  important  that  all  relevant  variables  be  appropriately 
treated.  For  example,  the  ingress  altitude  of  the  strike  force  (which  is  not 
treated  by  the  Route  Planner)  probably  has  as  much  impact  on  fuel  consumption 
and  probability  of  detection  (and  the  consequent  effectiveness  of  the  strike 
mission)  as  does  the  flight  speed  of  the  strike  force  (which  is  treated  by 
the  Route  Planner)  for  most  air  strike  situations.  In  ASTDA,  the  probable 
duration  of  an  air-to-air  engagement  should  be  considered  and  the  planned 
or  expected  motions  of  sensor  platforms  should  be  considered  in  both  route 
planning  and  in  EMCON  planning.  Some  of  the  variables  of  the  separate  aids  i 
must  also  be  consolidated  in  order  to  avoid  burdening  the  decision  maker  with 
redundant  requests  for  data.  Examples  are  the  disparate  parameters  for 
fighting  capability  of  force  elements  in  ASTDA,  EWAR,  and  SOC. 


A particularly  important  issue  to  be  considered  concerns  the  treat- 
ment of  uncertainty  associated  with  data  estimates  for  the  different  variables 
to  be  used  in  the  integrated  system.  Most  of  the  variables  involved  in  the 
process  models  and  value  models  of  the  separate  aids  refer  to  information  for 
which  precise  objective  measurement  is  infeasible.  Variables  like  fighting 
capabilities,  future  weather  conditions,  future  force  readiness,  and  even 
current  force  locations  have  highly  variable  degrees  of  uncertainty.  The 
different  aids  currently  have  different  strategies  for  dealing  with  the 
uncertainty  in  their  variables.  SOC  and  EWAR  assume  that  all  uncertain 
variables  take  on  their  expected  values.  Consequently,  all  modeled  processes 
can  be  treated  as  deterministic.  The  Route  Planner  assumes  that  the 
enemy  sensor  locations  are  known  but  treats  the  output  variables  representing 
detection  of  the  strike  force  by  the  enemy  as  probabilistic.  ASTDA  offers 
the  most  comprehensive  treatment  of  uncertainty  of  the  candidate  aids  by 
treating  weather  conditions  as  probabilistic  and  by  describing  both  input 
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force  readiness  and  output  force  attrition  in  terms  of  statistical  distribu- 
tions. These  differing  representations  of  uncertainty  derive  from  a variety 
of  considerations  ranging  from  expediency  to  general  decision  aiding 
philosophy. 


Some  of  the  major  arguments  against  the  explicit  treatment  of 
uncertainty  in  decision  aids  are: 

• Parameters  that  quantify  uncertainty  are  difficult  to  estimate 
and  cannot  be  estimated  reliably. 

• Inclusion  of  uncertainty  parameters  generates  an  unmanageable 
quantity  of  information  to  be  considered  by  the  user  of  the 
decision  aid. 

• Predictions  of  average  outputs  based  on  average  inputs  are 
just  as  accurate  as  uncertainty  incorporating  predictions 
in  most  cases. 

• It  is  virtually  impossible  to  describe  accurately  the  inter- 
relations between  the  uncertainties  associated  with  related 
variables. 

• In  order  for  any  moderately  complex  model  to  relate  input 
uncertainties  to  output  uncertainties,  it  must  be  used  in 
Monte  Carlo  fashion  which  tends  to  be  costly  in  terms  of 
computer  time  and  storage  requirements. 

• Expressions  of  uncertainty  associated  with  predictions  are 
difficult  to  interpret  and  tend  to  obscure  any  trends  that  are 
present  in  the  average  predictions. 


On  the  other  hand,  some  of  the  major  arguments  in  favor  of  the 
inclusion  of  some  uncertainty  measures  in  decision  aiding  systems  are: 

• If  ranges  of  uncertainty  do  not  accompany  aid  predictions,  then 
it  will  be  difficult  to  judge  the  correspondence  between 
observed  results  and  predicted  results  which  is  an  important 
factor  in  determining  the  user's  confidence  in  the  aid. 

t Uncertainties  around  average  predictions  are  important  for 
many  decision  makers  since  they  enable  consideration  of  the 
full  range  of  likely  results  and  the  development  of  subsequent 
contingency  plans  (e.g.,  rescue  operations). 
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• Uncertainty  of  results  is  demonstrably  an  important  considera- 
tion for  most  decision  makers  who  exhibit  various  degress  of 
risk  aversion. 

• Uncertainty  in  input  conditions  can  be  an  important  deter- 
minant of  average  outputs  in  some  significant  situations. 

(For  example,  Craig,  1975,  in  a systematic  study  of  deter- 
ministic and  stochastic  engagement  models,  concluded  that 
input  uncertainties  significantly  influence  outputs  when 
adversary  forces  are  small  or  near  parity.) 

• People  can  learn  to  estimate  probabilities  reliably  in  many 
situations  and  may  well  be  able,  with  appropriate  training, 
to  provide  accurate  estimates  of  probabilistic  data  involved 
in  a task  force  campaign. 

• Awkward  assumptions  and  interpretations  are  frequently  required 
to  deal,  with  deterministic  analogs  of  genuinely  stochastic 
processes. 


A previous  study  in  the  ODA  program  has  addressed  the  issue  of 
whether  or  not  information  about  outcome  uncertainty  is  useful  to  a decision 
maker  (Gettys,  Moy,  and  O'Bar,  1976),  but  several  problems  in  their  experi- 
mental design  prevented  any  firm  conclusions  from  being  drawn.  In  particular, 
it  was  not  clear  whether  the  uncertainty  incorporated  in  the  decision  aids 
studied  was  effectively  displayed.  At  the  same  time,  it  was  clear  that 
neither  of  the  aids  used  in  the  study  responded  appropriately  to  the  event 
of  chief  concern,  a change  in  enemy  intentions.  At  least  one  experimental 
study  (Laios,  1978)  has  demonstrated  that  the  display  of  uncertainty  informa- 
tion can  enhance  decision  making  performance,  but  that  study  was  concerned 
with  an  industrial  scheduling  problem  that  is  rather  remote  from  the  task 
force  command  and  control  environment. 


For  lack  of  compelling  evidence  on  either  side  of  the  uncertainty 
issue,  it  seems  reasonable  to  take  a compromise  position  and  design  an  inte- 
grated system  in  which  uncertainty  is  a user-controlled  option.  If  the  user 
chooses  not  to  deal  with  uncertainty  he  can  estimate  all  inputs  at  their 
average  expected  values  and  force  the  application  of  a deterministic  version 
of  any  relevant  process  model  in  order  to  generate  outputs.  If  he  does  opt 
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for  the  modeling  of  uncertainty,  he  can  provide  probabilities  and  statistical 
distributions  for  appropriate  input  data  and  then  examine  the  results  of  a 
Monte  Carlo  simulation  of  the  stochastic  version  of  the  relevant  process 
model.  Some  effort  would  be  required  to  ensure  that  the  stochastic  and 
deterministic  form  of  all  process  models  were  really  comparable.  By  enabling 
people  to  address  a variety  of  task  force  decision  problems,  both  with  and 
without  consideration  of  uncertainty,  it  may  be  possible  to  determine  the 
conditions,  if  any,  under  which  it  is  advantageous  to  deal  explicitly  with 
uncertainty. 

3.5  OPTIMIZATION  AND  ANALYSIS 

The  only  automatic  optimization  functions  in  the  aids  to  be  inte- 
grated are  the  dynamic  programming  and  the  nonlinear  programming  algorithms 
provided  with  the  Route  Planner.  Both  of  these  procedures  constitute  system-  i 
atic  searches  for  optimum  values  of  nonlinear  functions  of  several  variables. 
For  the  particular  type  of  optimization  problem  addressed  by  the  Route  Planner, 
it  is  evident  that  the  semi-automatic  algorithm  of  nonlinear  programming  is 
more  suitable  than  the  completely  automatic  algorithm  of  dynamic  programming. 
However,  both  optimizing  routines  are  potentially  applicable  to  many  of  the 
problems  that  could  be  addressed  by  an  integrated  aid.  For  example,  problems 
like  optimizing  the  configuration  of  a strike  force  or  the  plan  for  emissions 
control  are  formally  similar  to  the  route  planning  problem.  It  is  not  yet 
clear  from  the  ongoing  experimentation  with  the  Route  Planner,  however,  whether 
or  not  any  type  of  automatic  optimization  can  significantly  improve  on  the 
manual  optimization  alternative.  If  automatic  optimization  is  called  for, 
further  research  is  required  to  determine  the  most  effective  ways  to  guide 
the  human  in  his  use  of  an  optimizing  algorithm.  The  nonlinear  program- 
ming procedure  in  the  Route  Planner  is  capable  only  of  finding  a local 
optimum  on  a complex  surface,  so  the  ingenuity  of  the  user  is  important 
in  locating  a global  optimum.  The  user  must  learn  to  structure  optimization 
problems  in  ways  that  will  ensure  that  useful  results  will  be  produced 
within  the  available  time.  Convergence  of  both  optimizing  algorithms  in  the 
Route  Planner  can  be  fairly  slow  even  with  the  relatively  simple  criterion 


function  used  in  that  system,  so  serious  response  time  problems  can  be  expected 
to  arise  for  more  complicated  criterion  functions.  By  restricting  the  range 
and  granularity  of  the  search,  the  user  can  exercise  considerable  control  over 
the  time  consumed  by  the  search.  Accordingly,  it  is  desirable  to  offer  assist- 
ance to  the  user  in  constructing  a search  that  will  be  appropriately  responsive 
to  his  needs.  The  system  might,  for  example,  estimate  the  time  that  will  be 
required  for  a specified  search  and  how  that  time  requirement  would  be  changed 
by  alterations  to  the  criterion  function,  convergence  criterion,  search  limits, 
and  search  granularity. 

The  sensitivity  analysis  capability  provided  in  ASTDA  is  also  appro- 
priate to  a variety  of  applications  in  the  integrated  system.  For  variables 
over  which  the  user  has  some  control,  the  sensitivity  analysis  can  be  used  to 
conduct  a limited  search  for  an  optimal  value  of  one  variable  at  a time.  In 
this  vein,  the  sensitivity  analysis  might  also  be  useful  in  determining  appro- 
priate limits  to  be  used  for  a variable  in  a more  comprehensive  automated 
search  for  optimal  levels  of  several  related  variables.  In  cases  of  variables 
for  which  the  user's  estimates  are  highly  uncertain,  the  sensitivity  analysis 
could  be  applied  to  determine  the  usefulness  of  initiating  courses-of-action 
to  reduce  the  uncertainty  (e.g.,  through  detailed  simulation  exercises  or 
reconnaissance  missions).  By  enabling  the  user  to  examine  the  covariation  of 
any  pair  of  input  and  output  variables  in  a process  model,  the  sensitivity 
analysis  can  also  aid  the  user  in  understanding  the  behavior  of  the  process 
model . 
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Additional  analysis  capabilities  that  could  be  useful  for  the  inte- 
grated aid  could  be  developed  from  standard  statistical  testing  and  modeling 
techniques.  The  user  could  be  provided  with  procedures  like  the  t-test  and 
the  F-test  for  comparisons  of  data  involving  statistical  uncertainty.  The 
technique  of  linear  regression  could  help  the  user  to  analyze  trends  in  noisy 
data.  These  and  other  statistical  analysis  tools  would  be  especially  important 
when  process  models  were  exercised  in  a stochastic  mode,  but  some,  like 
linear  regression,  could  be  useful  even  if  uncertainty  of  input  and  output  data 


was  not  treated  explicitly.  Although  no  statistical  analysis  functions  are 
provided  in  any  of  the  aids  currently  under  consideration,  it  would  not  be 
difficult  to  add  this  capability  in  an  integrated  system. 

Another  analysis  technique  that  has  not  been  exploited  by  the  current 
ODA  decision  aids  but  which  could  be  quite  useful  in  an  integrated  system  is 
war-gaming.  Some  aids,  like  ASTDA  and  EWAR,  attribute  fairly  simple  deterministic 
strategies  to  the  enemy,  an  approach  that  could  generate  sub-optimal  decisions 
in  cases  where  the  enemy  has  very  carefully  optimized  his  own  strategy.  Although 
the  decision  maker  will  generally  be  uncertain  about  the  strategy  employed  by 
the  enemy,  it  is  inappropriate  to  base  a decision  analysis  solely  on  the  simplest 
or  most  obvious  enemy  plan.  By  representing  the  strategies  of  both  adversaries 
in  equal  detail  and  by  enabling  the  decision  maker  to  analyze  the  enemy's  deci- 
sions as  well  as  his  own,  a decision  aid  could  be  developed  that  would  plan 
optimal  responses  to  the  enemy's  actions.  By  treating  the  adversary  plans 
symmetrically,  such  an  aid  could  be  used  to  play  out  a scenario  as  a war-game 
and  thus  ensure  thorough  consideration  of  enemy  options. 

3.6  DISPLAY  FEATURES 

A diverse  collection  of  display  techniques  are  represented  by  each  of 
the  decision  aids,  including  tables,  graphs,  and  maps.  Although  all  of  these 
display  types  are  appropriate  for  some  applications  in  the  integrated  system,  it 
is  important  to  avoid  confusing  the  user  with  arbitrary  variations  in  display 
format.  Standard  display  formats  should  be  adopted  for  the  new  aiding  system 
to  ensure  that  the  displays  will  be  easily  interpretable.  The  maps  generated  by 
EWAR  and  the  Route  Planner  to  display  force  locations  and  sensor  detection  rates 
should  use  similar  coding  and  labeling  techniques.  Standard  tabular  and  graphic 
formats  should  be  established  to  deal  with  the  types  and  quantities  of  available 
information.  Display  features  that  depend  on  idiosyncratic  hardware  capabilities 
should  be  avoided  until  it  is  clear  that  the  relevant  hardware  will  be  available 
in  the  task  force. 
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It  is  important  to  recognize  that  both  the  kind  of  information  and 
the  manner  in  which  it  is  displayed  are  critical  issues  for  interactive  decision- 
aiding  systems.  For  example,  in  the  case  of  the  Route  Planner  (in  the  nonlinear 
programing  optimization  mode),  the  time  required  to  discover  a globally  optimal 
path  is  dependent  on  the  user's  ability  to  provide  a good  initial  guess  for  the 
path.  This  is,  in  turn,  strongly  influenced  by  the  effectiveness  with  which  the 
information  is  displayed  to  the  user.  Accordingly,  it  would  be  worthwhile  to 
investigate  how  alternate  displays  of  information  might  impact  man-machine 
system  performance.  For  example,  it  might  be  more  effective  to  display  regions 
with  similar  detection  rates  through  gray  level  or  color  intensity  coding, 
rather  than  with  contours.  This  alternative  would  require  less  complicated  soft- 
ware and  would  generate  displays  more  rapidly  on  some  types  of  graphic  display 
systems.  Or  it  might  be  advantageous  to  transform  detection  rates  into  detec- 
tion probabilities  before  displaying  them.  This  can  be  accomplished  simply  by  ' 
exponentiating  each  detection  rate  and  subtracting  it  from  unity,  thus  generating 
the  probability  of  detection  in  a unit  time  interval.  This  derived  value  might 
be  more  meaningful  to  the  user  than  the  basic  detection  rate  because  it  has  a 
more  direct  impact  on  the  course  of  the  strike  engagement  as  well  as  on  the  par- 
ticular utility  function  currently  employed. 


Effective  use  of  graphic  displays  is  especially  important  in  decision 
aiding  because  of  the  human's  unique  ability  to  process  visually  presented 
spatial  information.  In  most  cases,  people  can  interpret  and  remember  spatially 
coded  information  much  better  than  equivalent  verbal  and  numeric  data.  For  some 
spatially  oriented  tasks,  like  the  choice  of  an  initial  path  for  the  Route 
Planner,  it  is  apparent  that  humans  are  much  more  efficient  than  any  available 
computer  program.  While  it  is  necessary  to  use  alphanumeric  data  representations 
for  functions, such  as  entering  and  updating  values,  it  is  desirable  to  supple- 
ment alphanumeric  displays  with  suitable  graphic  displays  of  the  same  data 
whenever  possible.  This  display  strategy  was  used  in  ASTDA's  parallel  graphic 
and  tabular  displays  of  the  major  input  and  output  data.  Supplementary  graphic 
displays  might  also  be  usefully  adopted  for  some  of  the  campaign  planning  func- 
tions addressed  by  the  SOC.  At  the  same  time,  readability  of  the  SOC  tabular 


displays  might  be  improved  by  structuring  the  displayed  information  somewhat 
differently  so  that  much  less  information  would  be  presented  in  each  display 
but  more  display  options  would  be  offered. 

3.7  ROLES  OF  HUMAN  JUDGMENT  AND  HEURISTICS 

Human  judgment  and  heuristic  procedures  are  critical  factors  in  any 
decision  aiding  system.  The  decision  aid  itself  represents  the  collected 
judgments  of  the  people  who  developed  the  system.  In  the  case  of  value  models 
especially,  the  model  represents  an  heuristic  shortcut  for  estimating  how  immediate 
outcomes  relate  to  remote  goals.  In  developing  an  integrated  decision  aiding 
system,  however,  the  most  critical  issue  regarding  human  judgment  concerns  the 
manner  in  which  the  system  interacts  with  the  judgment  of  the  user.  Some 
information  processing  functions  are  totally  automated,  whereas  others  are 
relegated  to  the  user,  with  assistance  from  the  system,  and  still  others  are  i 
left  completely  to  the  user.  Ideally,  this  kind  of  division  of  labor  results 
in  an  optimal  allocation  of  responsibilities  to  the  human  and  the  machine  with 
regard  to  their  relative  capabil ities. 

For  each  of  the  separate  aids  involved  in  the  integration  effort,  it 
is  the  responsibility  of  the  decision  maker  to  recognize  the  relevance  of  an  aid 
to  any  particular  problem  situation.  This  may  seem  to  be  a trivial  task,  since 
a route  planning  problem  calls  for  the  Route  Planner,  a strike  timing  problem 
calls  for  ASTDA,  and  so  on.  However,  the  matching  of  an  aid  to  a problem  could 
be  quite  difficult  in  some  cases.  As  each  of  the  aids  are  currently  configured, 
they  incorporate  strong  assumptions  about  what  factors  are  involved  in  ostensibly 
generic  decision  problems.  For  example,  in  ASTDA,  the  consequences  of  a strike 
launch  time  are  dependent  upon  the  time  variation  of  weather  conditions  and  force 
readiness  characteristics  of  each  adversary.  If  the  decision  maker  has  the  pro- 
blem of  choosing  a time  to  launch  an  air  strike  but  recognizes  additional  time 
varying  factors  of  concern,  such  as  offensive  enemy  actions  that  might  occur 
prior  to  the  strike,  then  he  might  be  unsure  about  the  advisability  of  using 
ASTDA  for  his  problem.  Similar  dilemmas  could  arise  with  any  of  the  other  aids 
whenever  there  are  factors  involved  in  the  decision  that  do  not  seem  to  fit  the 
assumptions  of  the  aid.  r x ~ \ 
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Even  whfe/i  the  applicability  of  an  aid  to  a problem  has  been  determined, 
the  current  aids  offer  little  flexibility  in  structuring  the  representation  of 
the  problem.  Generally,  values  for  input  variables  and  parameters  must  be  com- 
pletely specified  by  the  user  before  any  aid  outputs  can  be  obtained.  In  using 
the  SOC,  for  example,  the  user  must  supply  all  data  required  by  14  input  tables 
after  which  he  can  instruct  the  aid  to  simulate  the  campaign  described  by  that 
data  and  then  he  can  examine  the  campaign  results  displayed  in  five  output 
tables.  The  user  cannot  determine  the  level  of  detail  for  the  description  of 
the  problem  or  of  the  campaign  results.  The  SOC  must  be  used  in  the  same  way 
at  all  times,  no  matter  whether  the  user  is  undertaking  the  initial  formulation 
of  a complete  campaign  plan  or  the  analysis  of  a single  option  in  an  established 
plan.  The  SOC,  the  Route  Planner,  ASTDA,  and  EWAR  all  offer  highly  refined 
structures  into  which  the  user  must  fit  his  problem  if  he  is  to  use  the  aid 
at  all.  i 

More  flexible  approaches  to  decision  aiding  are  possible  and  should 
be  considered  when  designing  an  integrated  system.  For  example,  an  aiding 
system  could  help  the  user  to  structure  his  decision  problem  through  an  inter- 
active process  which  would  select  and  configure  appropriate  models  as  they  were 
identified.  The  Decision  Structuring  Aid  being  developed  by  SRI  International 
(Merkhofer,  et.  al.,  1977)  addresses  the  general  problem  of  decision  structuring. 
It  consists  of  a system  for  developing  and  analyzing  a decision  tree  repre- 
senting sequential  (or  otherwise  contingent)  decisions  and  events.  It  requires 
the  user  to  assign  values  subjectively  to  the  terminal  nodes  of  the  decision 
tree  as  defined  by  all  possible  combinations  of  relevant  variables  and  options 
for  both  adversaries.  However,  the  characterization  of  these  terminal 
conditions  can  be  complicated  and  because  there  can  be  a large  number  of  such 
terminal  nodes,  the  valuation  task  can  be  very  difficult  and  the  results 
unreliable.  In  order  to  utilize  the  capabilities  provided  by  the  four  problem- 
specific  aids,  it  is  desirable  to  have  a decision  structuring  tool  that  would 
help  the  user  develop  a suitably  detailed  problem  scenario  to  which  the  available 
models  could  be  applied.  At  the  same  time,  it  is  important  to  develop  more 
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flexible  versions  of  the  component  process  and  value  models  in  order  to 
enable  the  user  to  define  factors  of  interest  and  levels  of  detail  with 
which  to  treat  them. 
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4.  SPECIFIC  INTEGRATION  PLANS 


There  are  two  general  strategies  that  could  be  followed  to  develop 
an  integrated  decision  aiding  system  for  the  task  force  coirmand.  One 
approach  is  to  interface  the  separate  decision  aids  into  a system  in  which 
the  separate  aids  work  smoothly  together,  resulting  in  a system  that  is 
(hopefully)  more  useful  for  a broader  class  of  problems  than  the  separate 
aids.  We  will  call  this  approach  a bottom-up  design.  The  alternative,  a 
top-down  approach,  starts  with  a definition  of  global  system  objectives  and 
then  elaborates  on  those  objectives  until  a set  of  detailed  system  specifica- 
tions are  obtained.  The  bottom-up  approach  ensures  that  the  available  tech- 
nologies are  provided  to  the  decision  maker  in  an  efficient  package;  the 
top-down  approach  ensures  that  the  basic  needs  of  the  decision  maker  are 
addressed.  The  two  approaches  are  not  necessarily  mutually  exclusive  and 
parallel  development  of  both  may  well  be  worthwhile. 

4.1  THE  BOTTOM-UP  APPROACH 

There  are  a number  of  ways  in  which  the  separate  aids  could  be 
merged  into  a single  system  in  which  the  individual  inconsistencies  and 
incompatabil ities  are  resolved  and  the  duplications  of  function  consolidated. 

A key  consideration  is  the  level  of  effort  that  could  be  devoted  to  the  task. 
Accordingly,  we  will  describe  a basic  integrated  system  and,  with  respect 
to  each  part  of  the  system,  a number  of  optional  features  that  deserve 
serious  consideration. 

In  addition  to  solving  the  interface  problems,  certain  new  aid 
features  should  be  developed  as  part  of  this  effort  to  improve  the  operational 
usefulness  of  the  integrated  system.  This  need  arises  from  the  fact  that  the 
aids  discussed  above  have  been  designed  more  for  experimental  and  demonstration 
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purposes  than  for  operational  use.  The  principal  deficiencies  that  must 
be  remedied  to  improve  their  operational  usefulness  concern  the  specific 
variables  incorporated  in  the  component  process  and  value  models. 

Only  the  first  stage  of  a bottom-up  integration  will  be  described. 
It  is  our  belief  that  initial  development  of  the  integrated  aid  should  focus 
on  the  decision  problems  associated  with  planning  a single  air  strike  and 
that  subsequent  development  should  expand  the  system  to  address  broader 
campaign  planning  problems.  For  this  first  stage  of  development,  then,  the 
components  to  be  integrated  will  be  ASTDA  and  the  Route  Planner.  Many 
features  of  the  first  stage  plan,  however,  are  intended  to  facilitate  later 
incorporation  of  EWAR  and  SOC  functions.  To  facilitate  reference  to  the 
proposed  system,  we  will  call  it  SCAMP-1  as  the  first  stage  version  of 
the  Strike  Campaign  Planning  Decision  Aid.  The  general  structure  of  SCAMP-1 
is  diagrammed  in  Figure  4-1. 


4.1.1 


Target  Problems 


SCAMP-1  is  designed  to  aid  the  user  in  planning  all  major  aspects 
of  a single  air  strike  against  a ground  or  sea  target.  Such  factors  as 
approach  route,  launch  time,  strike  force  complement  and  allocation  of  strike 
aircraft  to  targets,  will  be  addressed  by  the  aid.  The  user  will  be  able 
to  analyze  tactical  variables  for  either  the  offensive  or  defensive  adversary 
in  order  to  test  his  plans  against  optimal  enemy  plans.  Attacks  against 
naval  forces  in  the  open  sea  will  be  treated  in  addition  to  attacks  against 
land-based  installations,  in  order  to  expand  the  ASTDA's  domain  of  applica- 
bility and  to  anticipate  a system  that  will  be  compatible  with  EWAR  and  SOC. 
The  aid  is  being  designed  to  be  used  principally  in  the  timeframe  of  from 
one  hour  to  one  day  before  the  strike  is  actually  to  be  launched.  However, 
much  of  the  data  required  by  the  aid  could  be  supplied  well  before  the  strike 
decision  was  analyzed.  In  fact,  the  aid  could  be  used  on  a continuing  basis 
to  keep  track  of  the  user's  and  the  enemy's  resources  and  force  locations. 

The  aid  will  be  configured  for  multiple  terminal  access  so  that  data  can  be 
supplied  continuously  by  subordinate  officers  under  the  supervision  of  the 
principal  decision  maker.  ( 7^  > 
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INPUTS 

CANDIDATE  ROUTES 
SENSOR  CAPABILITIES 
FLIGHT  SPEEDS  AND  ALTITUDES 
TASK  FORCE  AND  TARGET  LOCATIONS 
SENSOR  LOCATIONS  AND  MOTIONS 
WEATHER  PREDICTIONS 
FORCE  READINESS  PREDICTIONS 
ENGAGEMENT  CAPABILITY  PARAMETERS 
TARGET  ASSIGNMENT  PARAMETERS 


OUTPUTS 

• UTILITIES  OF  ROUTES  AND  ENGAGEMENTS 

• FUEL  CONSUMPTION  ON  INGRESS 

• MEASURE  OF  PROBABLE  DETECTION  TIME 

FOR  INGRESS  ROUTE 

• COMPOSITE  DETECTION  PROBABILITY  MAP 

• FORCE  UNIT  ATTRITION  AS  LOSSES 

AND  PARTIAL  DAMAGE 

• SENSITIVITY  DISPLAYS 

• LOSSES  BY  MISSION  SEGMENT 


ENGAGEMENT 

MODEL 


ENGAGEMENT  VALUE 
MODEL 


ROUTE  VALUE 
MODEL 


ANALYSIS  FEATURES 

• NONLINEAR  PROGRAMMING  OPTIMIZATION 
o SENSITIVITY  ANALYSIS 

• LAUNCH  TIME  ANALYSIS 

• INTRA-PROCESS  ANALYSIS 

• DERIVATION  OF  ROUTE  VALUE  MODEL 

FROM  ENGAGEMENT  RESULTS 


Figure  4-1.  SCAMP-1  Structure 


4.1.2 


Process  Models 

The  model  of  the  strike  engagement  for  SCAMP-1  will  be  an  adapta- 
tion of  the  ASTDA  engagement  model.  The  model  will  be  stochastic  so  that  the 
uncertainty  inherent  in  the  engagement  process  will  be  included,  but  it 
will  also  be  possible  to  exercise  the  model  in  a deterministic  fashion  by 
having  all  stochastic  processes  take  on  their  expected  values.  Some  significant 
modifications  to  the  ASTDA  model  will  be  required  in  order  to  make  the  engage- 
ment sensitive  to  the  features  of  the  approach  path  provided  by  the  route 
planning  functions.  The  model  will  describe  how  the  size  of  the  defending 
interceptor  force  and  the  duration  of  the  air-to-air  engagement  between  the 
strike  force  and  the  interceptor  force  are  influenced  by  the  point  at  which 
the  approaching  strike  force  is  detected  by  enemy  radar.  Fuel  consumption  by 
both  the  strike  force  and  the  interceptor  force  will  also  be  factored  into  the 
engagement  model  to  represent  the  relationship  between  fuel,  fighting  capa- 
bility, and  aircraft  survival.  Estimates  of  damage  to  adversary  force  ele- 
ments will  be  output  by  the  model  in  addition  to  the  binary  survival/destruc- 
tion outputs  currently  provided  by  ASTDA.  Damage  estimates  are  needed  to 
describe  the  results  of  air  strikes  against  ships  and,  when  the  aid  is 
expanded  to  incorporate  the  longer  range  planning  functions  of  SOC,  to  des- 
cribe how  force  readiness  is  affected  by  repair  of  damaged  systems. 

In  addition  to  a more  detailed  strike  engagement  model,  a model  is 
needed  that  will  describe  the  detection  of  the  approaching  strike  force  by 
enemy  radar  stations.  The  radar  detection  model  in  the  Route  Planner  will 
form  the  basis  for  this  model.  In  addition  to  being  sensitive  to  the 
characteristics  of  the  radar  system  and  the  distance  between  the  radar  and 
the  target,  the  model  must  be  sensitive  to  the  interrelationships  between 
the  probability  of  detection  and  the  numbers  of  targets,  their  sizes  and 
altitudes,  and  the  weather  conditions  in  the  area.  In  addition,  it  will  have 
to  model  the  fact  that  both  fuel  consumption  rate  and  radar  detection  rate 
are  strongly  influenced  by  the  altitude  at  which  the  strike  force  flies. 
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4.1.3  Value  Models 

Two  separate  value  models  will  be  incorporated  in  SCAMP-1  in  order 
to  enable  candidate  approach  routes  to  be  evaluated  without  requiring  the 
engagement  model  to  be  run.  One  value  model  will  be  concerned  with  the 
valuation  of  engagement  results  and  the  other  will  deal  with  the  approach 
path  by  itself.  A linear  additive  model  based  on  force  unit  destruction, 
much  like  the  value  model  in  ASTDA,  will  be  used  for  the  former  purpose. 
However,  unlike  the  ASTDA  value  model,  it  will  assign  values  to  fractional 
destruction  of  force  units  rather  than  to  pure  survival  or  loss.  For  the 
valuation  of  the  approach  route,  the  value  model  will  use  the  same  types  of 
parameters  as  in  the  Route  Planner  but  with  considerable  added  flexibility 
for  the  functional  form  of  the  model.  The  two  input  components  of  the  value 
function  for  the  approach  route  will  be: 

I 

(1)  Probability  that  the  strike  force  will  be  detected  weighted 

by  the  time  prior  to  reaching  the  target  at  which  each  possible 
detection  point  is  passed,  and 

(2)  Amount  of  fuel  consumed  during  ingress. 

The  first  component  can  be  defined  mathematically  in  terms  of  the  path  seg- 
ment detection  probabilities,  where  the  path  segments  are  defined  either  by 
the  waypoints  identified  by  the  user  (or  route  optimizer)  or  as  more  finely 
divided  equally  spaced  segments.  If  there  are  n path  segments  and  p.  is  the 

t h * 

probability  of  detection  for  the  ktn  segment  and  t.  is  the  time  it  will  take 

f h ^ 

to  move  from  the  middle  of  the  k segement  to  the  target,  then  the  first 
component  input  to  the  value  function  is 


n 

E 

k=l 


pkV 


The  above  formula  will  replace  the  cumulative  detection  probability  used 
in  the  current  Route  Planner  to  index  route  value.  It  is  an  improvement  on 
the  current  equations  because  the  cumulative  detection  probability  neglects 
the  fact  that  it  is  not  just  whether  detection  occurs,  but  when  the  detection 
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occurs  that  influences  mission  effectiveness.  The  particular  function  that 
will  be  used  to  combine  the  two  value  components  will  be  determined  through 
a systematic  analysis  of  the  relationship  between  these  components  and  the 
value  assigned  to  subsequent  engagement  results  rather  then  by  an  arbitrary 
combination  rule.  Such  an  analysis  should  be  repeated  every  time  that  engage- 
ment conditions  change  significantly  because  the  influence  of  fuel  and  detec- 
tion on  engagement  value  probably  depends  on  the  sizes  and  relative  capa- 
bilities of  the  adversary  forces. 

4.1.4  Decision  Variables,  System  Variables,  and  System  Parameters 

There  will  be  only  minimal  restrictions  on  the  roles  of  the  variables 
in  the  process  models  in  SCAMP-1.  The  user  will  be  provided  access  to  all 
variables  of  conceivable  interest  to  him.  In  addition  to  the  variables 
included  in  the  Route  Planner  and  ASTDA,  SCAMP-1  will  deal  with: 


li 


0 Flight  altitude  of  the  strike  force  on  ingress, 

t Effective  sizes  of  strike  aircraft  to  enemy  radar, 

0 Movement  of  enemy  radar  stations  (as  constant  velocity 
vectors),  and 

0 The  effects  of  damage  on  the  capabilities  of  force  units. 

Force  readiness  variables  will  be  described  in  terms  of  probability 
distributions  over  possible  numbers  of  force  units,  as  in  ASTDA.  The  user 
will  have  the  option  to  let  each  individual  variable  take  on  its  expected 
value.  Several  types  of  passive  target  will  be  represented  to  distinguish 
destruction  probabilities  and  values  to  the  strike  force.  Weather  variables 
will  be  represented  somewhat  differently  than  in  ASTDA  to  eliminate  situations 
in  which  the  binary  representation  of  weather  as  either  good  or  bad  produces 
unrealistically  large  levels  of  uncertainty  in  the  output  distributions.  In 
SCAMP-1,  weather  will  be  treated  as  a continuous  variable  corresponding  to 
visibility  range  and  uncertainty  about  weather  as  a probability  distribution 
over  visibility  range.  Engagement  capability  parameters  will  continue  to  be 
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defined  with  respect  to  "good"  and  "bad"  weather  conditions  and  linear 
interpolation  will  be  used  to  generate  parameter  values  for  intermediate 
weather  states. 

There  are  several  optional  capabilities  that  should  be  considered 
if  time  and  cost  constraints  permit.  One  possibility  is  to  include  the 
uncertainty  in  enemy  radar  station  locations.  Rather  than  describe  station 
location  as  a latitude  and  longitude,  these  variables  could  be  described 
by  probability  distributions  that  quantify  the  estimater's  uncertainty. 

The  primary  problem  in  incorporating  the  uncertainty  associated  with  radar 
locations  is  in  the  description  of  the  impact  of  the  uncertainty  on  the 
detection  rate  for  a target  at  a fixed  location.  The  most  straightforward 
methods  for  relating  detection  rates  to  location  uncertainty  require  pro- 
hibitive computational  resources. 

Another  option  that  should  be  considered  would  allow  the  flight 
altitude  to  be  varied  over  the  legs  of  the  ingress  flight  path.  In  the 
proposed  standard  configuration  of  SCAMP-1,  the  user  defines  a single 
altitude  for  the  entire  ingress  flight.  The  suggested  option  would  allow 
the  decision  maker  to  define  the  flight  altitude  for  each  leg  of  the  flight 
path,  much  as  flight  speed  is  treated  currently  in  the  Route  Planner.  This 
added  flexibility  would  increase  the  complexity  of  the  displays  since  the 
decision  maker  would  have  to  work  with  composite  detection  rate  maps  for 
several  altitudes  simultaneously.  Possible  ways  of  solving  this  problem 
are  discussed  below  in  Section  4.1.6  on  Display  Features. 

4.1.5  Optimization  and  Analysis 

The  design  for  SCAMP-1  will  assume  that  optimization  of  route 
parameters  will  be  performed  manually,  although  allowance  will  be  made  for 
eventual  addition  of  an  automatic  optimization  procedure.  Sensitivity 
analyses  similar  to  those  in  ASTDA  will  allow  the  user  to  examine  the  covaria- 
tion of  any  single  input  variable  and  any  single  criterion  variable.  An 
ASTDA-like  analysis  of  the  relationship  between  launch  time  and  engagement 
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results  will  be  available  with  the  additional  possibility  that  different 
ingress  flight  paths  may  be  used  for  different  launch  times  (e.g.,  if 
varying  weather  conditions  produce  significant  variations  in  radar  detection 
rates).  The  intra-process  analysis  in  ASTDA's  loss-by-segment  displays  will 
also  be  used  in  SCAMP-1. 

In  addition,  there  will  be  new  analyses  in  SCAMP-1  to  perform  func- 
tions not  addressed  by  the  other  aids.  The  user  will  be  able  to  describe 
and  compare  engagement  results  for  several  distinct  sets  of  engagement  condi- 
tions corresponding,  for  example,  to  different  strike  force  complements  and 
target  assignment  rules.  This  type  of  analysis  is  a straightforward  exten- 
sion of  the  launch  time  analysis  in  ASTDA.  In  order  to  improve  the  computa- 
tional efficiency  of  the  system,  the  user  will  be  able  to  specify  an  automatic 
stopping  rule  for  the  sampling  of  simulated  strike  engagements.  Thus,  unlike  , 
ASTDA,  where  the  number  of  samples  is  a fixed  system  parameter,  the  sample 
size  used  in  SCAMP-1  may  be  either  specified  by  the  user  as  a fixed  number 
or  determined  dynamically  according  to  a set  of  user-specified  convergence 
criteria. 

The  application  of  the  nonlinear  programming  optimization  algorithm 
to  route  parameters  and  other  variables  will  be  reserved  for  a later  phase  of 
SCAMP-1  development.  Optimization  over  combinations  of  variables  such  as  strike 
force  complement  or  target  assignments  may  be  useful  to  a decision  maker  and 
could  be  treated  mathematically  in  the  same  way  as  the  route  optimization 
problem.  It  would,  however,  be  infeasible  to  use  a stochastic  engagement 
model  for  this  type  of  optimization  and  even  with  a deterministic  model  the 
amount  of  computer  time  required  for  the  procedure  may  be  unacceptable. 
Incorporation  of  automatic  optimization  in  the  SCAMP-1  system  should  be  con- 
tingent, in  any  case,  on  the  appearance  of  experimental  evidence  that  indicates 
that  automatic  optimization  can  reliably  produce  a significant  improvement 

{ 

* over  manual  optimization. 
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Display  Features 


The  principal  new  display  capabilities  that  will  be  developed  for 
SCAMP-1  relate  to  the  display  of  the  combined  detection  rates  of  all  enemy 
radar  sensors.  The  display  techniques  used  in  the  Route  Planner  will  have 
to  be  modified  to  reduce  display  generation  time  and  to  present  radar 
detection  information  in  a way  that  will  facilitate  identification  of  an 
optimal  flight  path.  In  order  to  construct  the  new  radar  detection  map,  a 
fairly  fine  grid  will  be  superimposed  over  the  map  area  (say,  50  x 50  or 
100  x 100).  For  each  cell  in  the  grid,  the  composite  detection  rate  will 
be  calculated  according  to  the  same  procedure  as  currently  used  in  the 
Route  Planner  except  that  the  basic  radar  detection  model  of  the  Route 
Planner  will  be  elaborated  to  incorporate  several  additional  factors. 
Calculated  detection  rates  will  then  be  converted  to  detection  probabi 1 ities 
for  unit  time  dwell  in  each  cell.  The  resulting  matrix  of  detection  prob- 
abilities will  then  be  converted  directly  to  a display  of  equal  detection 
probability  regions  by  collapsing  the  continuously  varying  detection  rates 
into  a few  probability  classes  and  assigning  a different  gray  level  or 
color  intensity  to  each  class.* 


The  basic  bar  graph  display  that  is  used  in  most  of  the  ASTDA 
displays  will  be  adopted  for  presentation  of  the  same  types  of  data  in  SCAMP-1. 
These  displays  enable  the  user  to  compare  the  distributions  of  a single 
output  variable  over  several  different  engagement  conditions  or  mission 
segments. 


*It  would  be  interesting  to  compare  the  quality  of  route  plans  pro- 
duced by  people  using  detection  rate  contour  maps  and  those  using  detection 
probability  region  maps. 
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If  the  user  is  allowed  to  vary  the  flight  altitude  of  the  strike 
force  over  the  legs  of  the  ingress  path,  new  display  techniques  must  be 
developed  so  that  the  user  can  examine  simultaneous  detection  probability 
maps  for  several  different  flight  altitudes.  Two  possible  ways  of  offering 
several  maps  at  one  time  are: 

(1)  Generate  hard  copies  of  each,  and 

(2)  Generate  four  maps  at  the  same  time  in  four  quadrants  of  the 
CRT  screen. 

By  using  the  latter  approach,  the  same  candidate  approach  path  could  be 
traced  on  all  four  maps  -at  the  same  time  in  order  to  help  the  user  see  the 
relevant  tradeoffs  in  detection  probability  and  altitude. 

4.1.7  Roles  of  Human  Judgment  and  Heuristics 

Human  judgment  will  be  used  in  SCAMP-1  in  basically  the  same  ways 
it  is  in  ASTDA  and  the  Route  Planner  separately.  It  will  continue  to  be 
necessary  for  the  user  to  identify  his  problem,  to  estimate  model  parameters 
so  as  to  represent  the  problem  situations,  and  to  select  the  analysis  pro- 
cedures that  can  help  him  to  make  a decision.  However,  the  new  display  and 
analysis  procedures  should  make  these  tasks  a little  easier  than  they  are 
currently  in  ASTDA  and  the  Route  Planner. 

4.2  THE  TOP-DOWN  APPROACH 

In  contrast  to  the  above  discussion  of  the  bottom-up  approach, 
there  are  relatively  few  details  about  the  top-down  approach  that  can  be 
offered.  The  components  of  the  bottom-up  approach,  the  separate  ODA  decision 
aids,  are  presently  available;  the  top-down  approach  must  start  with  a 
systematic  analysis  that  is  yet  to  be  undertaken.  The  object  of  the  analysis 
must  be  to  identify  the  needs  of  the  decision  maker  in  structuring  campaign 
planning  problems  and  in  formulating  global  objectives  for  the  campaign. 
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Although  the  SOC  provides  a structure  for  the  representation  of 


a task  force  campaign  plan,  it  does  not  assist  the  user  in  developing  the 

plan  or,  more  importantly,  in  defining  the  objectives  to  be  achieved  by  the 

plan.  The  first  step  in  attacking  the  campaign  planning  task  should  be  to 

define  the  purposes  of  the  campaign.  Purposes  should  be  specified  operationally 

in  terms  of  desirable  and  undesirable  end  situations  that  should  be  encouraged 

or  discouraged  by  the  task  force  campaign.  Objective  situations  could  be 

described  positively,  for  example,  as  the  situation  in  which  the  Orange  air 

strike  campaign  from  ONRODA  against  the  Grey  mainland  has  ceased  and  the 

Orange-supported  faction  in  Grey  has  not  taken  power;  or  they  could  be 

described  negatively,  for  example,  as  the  situation  in  which  the  major  world 
* 

power.  Red,  does  not  actively  support  Orange  in  the  war  between  Orange  and 
Grey.  Once  the  situations  that  are  potentially  of  consequence  to  the  task 
force  campaign  have  been  enumerated  and  described  at  a gross  level,  it  is 
necessary  to  add  details  to  the  situation  descriptions  in  order  to  make  goal 
satisfaction  verifiable.  At  this  point,  factors  such  as  timing  of  events 
and  possible  mitigating  circumstances  must  be  considered.  Next,  the  charac- 
teristics of  the  elaborated  objective  situations  must  be  related  either 
deterministically  or  probabilistically  to  the  variables  represented  in  the 
available  process  models.  For  example,  at  this  stage,  the  analysis  might 
call  for  a probability  distribution  to  describe  the  expected  relationship 
between  force  attrition  and  the  Orange  commander's  decision  to  cease  launch- 
ing air  strikes  against  Grey.  Before  considering  any  action  options,  all 
interrelations  between  the  objective  situations  should  be  analyzed  to  ensure 
that  they  are  mutually  exclusive  and  independent  of  one  another.  Finally, 
after  considering  all  the  aspects  of  the  above  analysis,  the  decision  maker 
would  assign  values  to  each  of  the  situations  considered.  The  result  of 
this  procedure  would  be  the  determination  of  surrogate  values  for  variables 
that  can  be  related  by  process  models  to  variables  under  the  control  of  the 
decision  maker. 

The  above  goal  analysis  procedure  is  admittedly  sketchy  and 
considerable  elaboration,  but  it  should  be  clear  that  it  represents  a 
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significant  departure  from  the  Decision  Structuring  Aid  (Merkhofer  et  al., 
1977).  The  above  procedure  calls  for  a thorough  analysis  of  objectives  prior 
to  any  consideration  of  action  alternatives  while  the  Decision  Structuring 
Aid  forces  the  decision  maker  to  define  and  analyze  plausible  actions  before 
considering  the  value  of  possible  results.  The  problem  with  the  latter 
approach  is  that  it  requires  the  decision  maker  to  perform  a very  difficult 
valuation  in  which  the  situation  being  assigned  a value  may  have  an  unclear 
relation  to  the  overall  campaign  objectives. 

Development  of  the  goal  analysis  approach  to  decision  structuring 
will  define  the  requirements  for  a campaign  simulation  model  and  the  appro- 
priate analysis  capabilities  to  be  used  with  the  model.  A somewhat  elaborated 
version  of  the  SOC,  with  a more  developed  engagement  model,  would  probably 
suffice  for  the  simulation  model,  though  the  specifications  for  the  Simula-  i 
tion  should  be  defined  only  after  some  initial  experimentation  with  the 
goal  analysis  in  the  task  force  planning  context. 


It  should  be  noted  that  the  goal  analysis  procedure  is  not  an 
alternative  to  the  Decision  Structuring  Aid,  but  rather  a supplementary 
procedure  for  addressing  the  problem  of  defining  a value  function.  The 
decision  tree  structuring  components  of  the  Decision  Structuring  Aid  would 
be  quite  useful  in  a campaign  planning  aid,  but  only  when  values  can  be 
assigned  reliably  and  consistently  to  terminal  situations. 


In  summary,  the  top-down  approach  to  an  integrated  decision  aiding 
system  could  provide  the  decision  maker  with  a tool  to  guide  him  in  a top- 
down  analysis  of  his  decision  problems.  The  system  begins  each  analysis 
with  a thorough  definition  of  goals  that  are  systematically  related  to  pre- 
dictable (though  perhaps  uncertain)  results  of  actions  that  may  be  made  by 
the  decision  maker  and  his  adversaries.  Options  for  action  are  then  analyzed 
and  contingency  plans  are  developed.  A comprehensive  campaign  simulation 
model  is  then  exercised  and,  along  with  the  value  model  constructed  at  the 
outset,  value  distributions  can  be  derived  for  each  string  of  actions, 
adversary  responses,  and  uncontrolled  events.  > — r — 
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5.  GENERAL  SOFTWARE  STRUCTURE 


There  are  several  phases  in  the  representation  of  a decision  prob- 
lem. The  decision  maker  must  specify  and  describe  his  problem  in  terms  of 
the  established  operations  and  contingency  plans,  the  decision  alternatives, 
and  the  value  model  involved.  This  can  be  termed  the  Problem  Specification, 
or  PS,  phase.  But  the  mere  statement  of  a problem  does  not  necessarily  define 
what  will  be  considered  as  the  information  needed  to  solve  the  problem.  The 
desired  solution  must  also  be  described  in  terms  of  the  decision  variables, 
decision  criteria,  and  analysis  forms  to  be  used.  This  can  be  termed  the 
Solution  Description,  or  SD,  phase.  The  description  of  the  solution  is 
clearly  spearate  from  the  description  of  the  problem,  yet  it  is  also  depen- 
dent on  it  because  each  type  or  class  of  decision  problem  has  only  a limited 
number  of  criteria  or  variables  through  which  a solution  may  be  defined. 

The  model  of  the  real  world  that  is  used  to  generate  the  desired 

solution  to  the  problem  must  be  based  on  empirical  data  (or  lacking  this, 

informed  judgments)  concerning  the  characteristics  of  the  processes  being 
modeled.  The  creation  of  this  empirical  data  base  can  be  termed  the  Perma- 
nent Data  Base  Establishment,  or  PDE,  phase.  Each  of  the  process  models  of 

the  various  aids  described  above,  for  example,  requires  a large  number  of 
parameter  values  which  represent  features  or  capabilities  of  weapons  plat- 
forms, sensors,  etc.  In  the  case  of  the  integrated  aid,  these  data  would 
include  such  things  as  maps,  aircraft/ship  sensor  performance  statistics, 
combat  engagement  statistics,  or  invariant  tactical  information.  While 
these  empirical  data  or  judgments  are  obtained  and  entered  to  a decision 
aid  independently  of  any  specific  problem  or  its  solution,  the  permanent 
data  to  be  used  in  solving  a given  problem  are  totally  determined  by  the 
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PS  and  the  SD  and  the  process  models  used.  PS,  SD,  and  PDE  represent  con- 
ceptually distinct  components  of  a decision  aiding  system,  yet  in  the  context 
of  a specific  problem  they  have  clear  logical  interrelations.  This  suggests 
that  a general  software  organization  for  the  integrated  aid  can  be  developed 
in  terms  of  the  PS,  SD,  and  PDE  functions. 

In  each  of  the  four  separate  aids,  this  three-part  structure  is 
present  but  not  explicit  because  each  aid  was  designed  to  address  only  one 
type  of  decision  situation  or  problem  and  because  the  aids  are  currently 
configured  more  for  demonstration  and  experimentation  purposes  than  for 
operational  use.  Each  aid  provides  only  a fixed  (though  sometimes  fairly 
exhaustive)  set  of  decision  making  criteria  as  outputs,  and  since  the  problem 
type  and  decision  criteria  are  hard-wired,  the  background  data  are  also 
hard-wired,  or  at  best  very  tightly  constrained.  No  distinction  is  made  in  1 

the  separate  aids  among  the  PS,  SD,  and  PDE  functions  because  there  is  no 
flexibility  in  these  functions.  In  the  SOC  and  ASTDA  aids,  for  example,  all 
the  displays  can  be  selected  from  a single  "menu,"  whether  the  displays  are 
intended  for  PS,  SD,  or  PDE  purposes. 

Such  hard-wiring  should  be  avoided  in  any  complex,  computer-based 
decision  aid.  Each  time  the  integrated  aid  is  used,  a problem  and  a solution 
must  be  specified,  and  background  data  (if  not  already  present)  must  be  pro- 
vided. Of  course,  the  solution  criteria  possible  and  the  background  data 
needed  will  be  determined  by  the  choice  of  a decision-making  problem.  Since 
the  type  of  problems  to  be  considered  by  an  integrated  decision  aid  are 
quite  varied,  the  kinds  of  problem  description,  solution,  and  background  data 
that  may  be  used  by  the  aid  must  also  be  diverse.  In  any  single  application, 
not  all  (or  perhaps  not  even  many)  of  the  possibilities  will  actually  be  used. 
The  decision  maker  should  only  be  required  to  deal  with  those  issues  relevant 
to  his  problem;  the  rest  of  the  possibilities  should  be  transparent  to  him. 

So  in  the  integrated  aid,  there  should  be  three  basic  functions  at  the  highest 
level  of  the  system: 
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(1)  Problem  Setup/Recall  — which  consists  of  specifying 
(a)  an  operations  scenario  (e.g.,  who  is  where,  with 
what  resources,  under  what  weather  conditions),  (b) 
a set  of  alternative  courses-of-action,  and  (c)  a 
value  model  for  the  problem.  These  data  constitute 
a Problem-Specific  Data  Base  (PSDB)  which  logically 
must  be  entered  in  the  above  order.  A PSDB  may  be 
stored  and  recalled  later  for  further  analysis  or 
modification. 

(2)  Viewinq/Entering/Updating  Background  Data  --  which 
consists  of  interfacing  a user  (who,  in  this  case, 
may  not  be  the  decision  maker)  with  all  the  background 
information  needed  by  the  various  decision  aiding  models. 
These  data  form  a Permanent  Data  Base  (PDB). 

(3)  Solution  Setup/Output  Request  — which  consists  of 
specifying  the  decision  criteria  to  be  used  and  the 
output  variables  and/or  forms  of  analysis  desired 
(e.g.,  outcome  predictions,  utility  predictions, 
sensitivity  analysis,  and  optimization).  These 
requests,  combined  with  the  PSDB,  will  result  in 

a particular  decision  aiding  algorithm  being  selected 
and  run  (using  data  from  PDB)  and  the  desired  results 
being  made  available  to  the  decision  maker. 


This  organization  is  diagrammed  in  Figure  5-1.  The  vertical  arrows 
indicate  control  flow,  and  the  horizontal  arrows  indicate  logical  sequences 
in  which  the  information  must  be  entered.  For  update/viewing,  the  order  is 
irrelevant.  The  background  data  function  would  normally  not  be  conducted 
by  the  decision  maker  (but  by  subordinates)  and  could  be  entirely  transparent 
to  him  unless  he  undertook  a problem  for  which  the  needed  data  was  absent. 
This  situation  would  cause  an  alert  indicating  that  the  calculations  were 
being  performed  without  all  the  needed  data,  or  would  force  the  entry  of 
the  missing  information. 


While  certain  modifications  will  be  required  to  make  the  individual 
aids  work  synergistical ly  on  new  problems,  this  organization  can  even  accom- 
modate the  separate  aids  as  they  now  stand.  It  is  primarily  a superstruc- 
ture to  be  built  on  top  of  the  other  SCAMP  software  to  tie  it  all  together 
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and  to  allow  inclusion  of  new  functions  and  programs.  To  clarify  how  this 
organization  would  appear  to  the  user,  an  example  user  interface  is  pro- 
vided in  the  appendix. 

A permanent  data  base  that  is  appropriate  for  the  SCAMP  system 
has  been  developed  in  the  ODA  programs  (CTEC,  Inc.  1976,  1977).  Since  the 
ODA  Data  Base  represents  the  structure  and  content  of  the  kind  of  Navy  data 
bases  that  might  be  available  in  the  coming  decade,  development  of  the 
integrated  decision  aid  on  that  foundation  should  facilitate  eventual  imple- 
mentation of  the  aid  in  the  fleet.  It  is  appropriate  to  make  maximum  use 
of  data  that  is  currently  represented  in  that  data  base  in  defining  the 
input  variables  and  parameters  for  the  SCAMP  system. 
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6.  CONCLUSIONS  AND  RECOMMENDATIONS 


This  report  has  surveyed  several  of  the  available  ONR  decision 
aiding  systems  that  address  aspects  of  the  problems  of  planning  air  strike 
missions  and  extended  naval  task  force  campaigns.  The  characteristics  of 
these  aids  have  been  described  with  regard  to  how  they  could  potentially 
interface  with  one  another,  the  operational  completeness  of  the  problem 
representations  in  each  aid,  and  the  decision  structuring  needs  of  the  deci- 
sion maker.  In  these  descriptions,  some  incompatibilities  among  the  aids 
were  noted  and  suggestions  were  made  as  to  how  these  incompatibilities  could 
best  be  overcome  in  an  integrated  decision  aiding  system.  In  seeking  to 
overcome  the  incompatibilities  among  the  individual  decision  aids,  a number 
of  desirable  attributes  for  the  integrated  system  have  guided  our  considera- 
tions: 

• Consistency 

--  Separate  models  for  the  same  process  should  be  consolidated. 

--  Separate  ways  of  assigning  value  to  the  same  type  of 
criteria  should  be  reconciled  in  a single  value  model. 

— Values  for  short-term  objectives  should  be  appropriately 
related  to  long-term  objectives. 

— Definitions  of  data  variables  should  be  consistent. 

— Arbitrary  variations  in  display  format  should  be  avoided. 

• Validity 

--  Operationally  appropriate  input  variables  should  be 
represented  in  process  and  value  models. 

--  Output  variables  should  be  relevant  to  the  decision  process. 
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--  The  value  model  should  accurately  translate  short-term 
and  long-term  objectives  into  preferences  on  process 
model  outputs. 

--  The  structure  of  the  process  models  should  conform  to 
real-world  task  force  situations. 

0 Flexibility 

--  It  should  be  possible  to  configure  parameters  and  options 
in  the  process  models  to  represent  all  scenarios  of 
potential  interest. 

— It  should  be  possible  to  tailor  the  value  model  to  describe 
all  objectives  of  major  concern. 

— Definitions  of  data  variables  should  admit  representation 
of  all  realizable  situation  characteristics. 

— The  user  should  be  able  to  apply  general  analysis  pro- 
cedures to  a maximum  range  of  specific  questions. 

— The  aid  should  be  compatible  with  the  information  and 
analysis  needs  and  the  decision  making  styles  of  all 
individuals  who  will  use  the  system. 

0 Efficiency 

--  Minimal  information  supplying  tasks  should  be  imposed  on  the 
user. 

— Minimal  demands  on  computer  resources  should  be  made  both 
in  terms  of  processing  time  and  storage  requirements. 

— Displays  should  not  be  cluttered  with  information  irrelevant 
to  the  user's  interests. 

0 Extendi bi 1 ity 

— It  should  be  possible  to  add  new  modeling  capabilities, 
problem  applications,  analysis  techniques,  and  display 
procedures  to  the  aid  without  being  forced  to  re-design 
the  entire  system. 

0 Understandabil ity 

--  The  user  should  be  able  to  understand  exactly  what  informa- 
tion is  requested  of  him  as  system  inputs. 
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--  The  user  should  be  able  to  interpret  system  outputs  in 
operationally  meaningful  terms. 

--  The  user  should  be  able  to  recognize  the  domain  of  problem 
situations  for  which  the  aiding  system  is  relevant. 

— The  user  should  clearly  understand  what  factors  are  included 
and  what  are  excluded  from  the  analyses  performed  by  the  aid. 

--  The  user  should  be  able  to  understand  all  options  available 
to  him  at  each  stage  of  aid  implementation. 

— Effective  system  design  should  minimize  the  prior  special 
training  required  for  an  individual  to  learn  to  use  the 
system  properly. 


Some  of  these  characteristics  tend  to  be  incompatible  with  one 
another  (e.g.,  representing  all  relevant  variables  and  minimizing  the  data 
input  task  for  the  user),  so  compromises  are  required.  But  the  integrated 
decision  aid  must  exhibit  all  of  these  characteristics  to  a reasonable  degree 
if  it  is  to  provide  an  effective  interface  between  component  decision  aiding 
functions  and,  at  the  same  time,  be  responsive  to  the  needs  of  the  decision 
maker. 


A number  of  general  issues  which  differentiate  decision  aiding 
methodologies  have  been  considered: 

• Uncertainty 

— Statistical  uncertainty  in  modeled  processes  and  data 

estimates  can  be  treated  explicitly  in  terms  of  variability 
measures  or  average  conditions  alone  can  be  described. 

--  Rather  than  adopting  either  alternative  alone,  process 
models  and  analysis  procedures  should  be  developed  that 
will  permit  the  user  of  the  aid  to  determine  which  alterna- 
tive treatment  of  uncertainty  to  employ  on  a case-by-case 
basis. 

• Valuation 

--  Valuation  of  process  results  can  be  achieved  through 

problem-specific  value  models  or  hierarchically  structured 
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value  models  can  be  developed  to  define  long-term  objectives 
and  to  relate  them  to  short-term  results. 

— Any  value  model  should  be  considered  as  an  optional  addition 
to  the  standard  presentation  of  predicted  unvalued  engage- 
ment outcomes.  Problem-specific  value  functions  should  be 
incorporated  in  the  integrated  system  with  value  parameters 
supplied  at  the  time  of  the  decision  analysis.  Research 
should  be  initiated  to  determine  a framework  for  the  defini- 
tion and  valuation  of  naval  task  force  objectives. 

• Optimization 

--  For  most  well-defined  processes  with  associated  value  models, 
it  is  possible  to  offer  mathematical  optimization  techniques 
which  determine  configurations  of  input  values  that  produce 
maximum  output  values  or  to  leave  the  search  for  optimum 
conditions  to  the  user. 

— The  initial  formulation  of  the  integrated  system  should  be 
oriented  toward  manual  optimization  procedures  and  experiments 
should  be  conducted  to  determine  if  significant  improvements 
over  the  manual  procedures  can  be  achieved  by  automatic  or 
semi-automatic  optimization  techniques. 

• War-Gami ng 

— A decision  aid  can  be  designed  to  deal  only  with  the  choices 
to  be  made  by  a single  decision  maker  or  with  the  choices 
of  both  adversary  decision  makers  in  the  form  of  a war-game. 

— The  integrated  aid  should  be  optionally  operable  in  a war- 
game  mode  in  order  to  ensure  realistic  treatment  of  the 
alternatives  open  to  the  enemy. 


Underlying  all  of  these  recommended  capabilities  of  the  integrated  aid  is  the 
idea  that  the  expertise  of  the  principal  decision  maker  and  his  staff  should 
be  thoroughly  incorporated  into  the  decision  process. 


Two  distinct  approaches  to  aid  integration  are  described;  both 
should  be  pursued  in  parallel.  A top-down  approach  addresses  the  problem  of 
defining  global  task  force  objectives,  relating  them  to  results  that  can  be 
modeled,  then  defining  the  model  and  analysis  requirements  at  the  highest 
level  of  the  system  to  be  developed.  A bottom-up  approach  focuses  on  the 


elimination  of  interface  problems  between  component  decision  aids  to  produce 
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an  efficiently  functioning  system.  A first  stage  application  of  this  approach 
is  described  for  decision  problems  associated  with  the  planning  of  a single 
air  strike  mission.  The  proposed  system,  called  Strike  Campaign  Planning 
Decision  Aid-1  (SCAMP-1)  is  comprised  principally  of  features  from  the  Route 
Planner  and  ASTDA. 


The  general  conclusions  reached  in  this  study  are  as  follows: 

• Although  the  four  problem-specific  aids  developed  in  the  ODA 
program  exhibit  effective  techniques  for  attacking  certain 
problems,  they  cannot  currently  be  used  effectively  together 
to  attack  problems  that  overlap  the  domains  of  the  separate 
aids  because  of  substantial  differences  in  process,  value,  and 
data  representations. 

• To  provide  reliable  valuation  estimates  for  the  available 

decision  aids,  the  decision  maker  requires  assistance  in  ■ 

relating  immediate  actions  to  long-term  goals. 

• The  user  of  the  integrated  aid  should  be  able  to  access  and 
analyze  sensitivities  to  virtually  all  variables  represented 
in  component  process  models. 

• The  engagement  models  in  ASTDA,  EWAR  and  SOC  can  be  made 
compatible  with  one  another  only  through  development  of  a 
consolidated  engagement  model  which  could  be  optionally 
exercised  in  deterministic  or  stochastic  modes. 

• The  value  models  in  the  Route  Planner,  ASTDA,  and  EWAR  can  be 
consolidated  in  a general  value  model  defined  in  terms  of  the 
destruction  to  both  adversary  forces  in  an  air  strike  against 
a land  or  sea  based  force  complex. 

• To  develop  a structure  for  a value  model  for  an  extended  task 
force  campaign,  as  represented  by  SOC,  it  is  necessary  to  under- 
take a systematic  analysis  of  the  types  of  long  term  objectives 
typically  addressed  by  task  force  campaigns. 


Principal  recommendations  for  continuing  development  of  an  integrated 
decision  aiding  system  are: 

• An  analysis  should  be  made  of  global  task  force  objectives 
in  diverse  scenarios  in  order  to  develop  a procedure  for 
determining  how  the  results  of  short-term  actions  influence 
the  achievement  of  long-term  goals. 
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• Further  development  of  system  requirements  with  respect  to 
the  construction  of  extended  campaign  plans  should  be  post- 
poned until  initial  development  of  both  SCAMP-1  and  the 
analysis  of  task  force  objectives  are  completed. 

• A bottom-up  approach  should  be  applied  to  the  development  of 
SCAMP-1  which  analyzes  problems  associated  with  the  planning 
of  a single  air  strike  mission. 


Specific  features  to  be  incorporated  in  SCAMP-1  should  be: 

(1)  A model  of  the  air  strike  engagement  for  land  and  sea  based 
targets  that  considers  the  effect  of  time  of  threat-detection 
on  defensive  response,  the  effect  of  in-flight  visibility  on 
air-to-air  and  air-to-ground  engagements,  and  description  of 
force  element  damage  along  with  aggregated  losses  and  survivals; 

(2)  The  capability  to  describe  uncertainty  in  input  data,  process 
events,  and  output  data  in  terms  of  statistical  distributions 
or,  optionally,  to  treat  all  data  as  fixed  and  processes  as  ' 
deterministic; 

(3)  A model  of  the  detection  of  an  air  strike  force  by  multiple 
radar  sensors  that  considers  characteristics  of  individual 
radars,  the  number  of  aircraft  in  the  strike  force  along  with 
their  sizes  and  flight  altitude,  and  weather  conditions  as 
described  by  in-flight  visibility  for  the  strike  force; 

(4)  A display  of  combined  radar  effectiveness  that  depicts  regions 
of  roughly  equal  probabilities  of  detection  in  a unit  time 
rather  than  contours  of  equal  detection  rates; 


(5)  Displays  of  basic  results  of  simulated  engagements  in  terms 
of  a variety  of  measures  such  as  damage,  losses,  attrition, 
survival,  and  aborts  by  force  unit  type; 

(6)  An  optional  value  model  for  engagement  results  based  on  damage 
and  force  losses  sustained  by  each  adversary; 

(7)  Displays  of  basic  approach  route  characteristics  in  terms  of 
detection  probability  and  fuel  consumption  over  the  legs  of 
the  path; 

(8)  An  optional  value  model  for  the  quality  of  a strike  approach 
route  based  on  fuel  consumption  and  detection  probabilities 
weighted  by  time  of  detection. 


(9) 


An  optional  stopping  rule  for  Monte  Carlo  sampling  of  the 
process  model ; 
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(10)  The  capability  to  analyze  alternate  strike  launch  times 
where  force  readiness,  weather,  and  approach  route  all  change 
with  time; 

(11)  The  capability  to  analyze  the  results  of  arbitrary  user- 
specified  configurations  of  engagement  characteristics 
(e.g.,  force  readiness,  weather,  approach  route,  target 
assignment,  strike  complement). 

Many  of  the  features  described  for  SCAMP-1  anticipate  later  inclusion 
of  the  models  and  analyses  of  EWAR  and  SOC  for  broader  issues  of  campaign 
planning.  A general  programming  structure  for  the  integrated  aid  based  on 
component  functions  of  permanent  data  base  establishment,  problem  specification, 
and  solution  description,  should  facilitate  all  future  extensions  and  modifica- 
tions of  the  system. 

The  initial  effort  required  to  develop  a working  version  of  SCAMP-1 
is  the  detailed  design  of  appropriate  mathematical  models  for  the  detection 
of  a strike  force  by  enemy  radars  and  the  engagement  of  adversary  forces. 
Designing  component  models  can  be  accomplished  fairly  quickly  since  the 
models  provided  by  ASTDA  and  the  Route  Planner  have  many  of  the  required 
characteristics.  Subsequent  implementation  of  SCAMP-1  as  a computer  program 
will  require  significant  modifications  to  routines  that  can  be  adapted  from 
existing  programs.  New  software  will  have  to  be  created  to  perform  new 
functions  that  have  been  radically  changed  from  other  aid  implementations. 
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APPENDIX 

SAMPLE  USER  INTERFACE 


After  calling  up  the  integrated  aid,  the  user  would  initially 
select  a type  of  function  for  the  current  run  from  an  initial  menu  asking 
to: 


SELECT  FUNCTION  TYPE: 

1.  UPDATE/REVIEW  PERMANENT  DATA  BASE 

2.  ENTER/RECALL  A DECISION  PROBLEM 

3.  DEFINE  SOLUTION/ RUN  MODEL 

4.  STOP 

If  the  first  alternative  were  chosen,  another  menu  would  appear  listing  the 
various  background  data  tables  in  the  permanent  data  base  that  were  available 
for  viewing  and  update.  For  example: 

SELECT  DATA  FOR  UPDATE/VIEWING: 

1.  PLATFORM  AND  SENSOR  ATTRIBUTES 

2.  ENGAGEMENT  STATISTICS 

3.  WEAPON  PLATFORM  AVAILABILITY 

4.  ELEMENT  TYPES 

5.  MAPS 

6.  END  FUNCTION 
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The  data  chosen  would  be  displayed  in  tabular  and/or  graphic  modes.  The  user 
would  then  have  the  option  of  updating  entries  or  exiting  from  the  menu. 

As  modifications  or  new  data  are  entered  to  the  PDB,  the  system 
will  perform  cross-checking  and  error-checking  operations.  These  will  pre- 
vent the  entry  of  erroneous  or  unacceptable  data,  and  will  suggest  or  per- 
haps even  require  entry  of  related  data.  For  example,  if  a new  element 
type  were  added,  say  an  F-18,  to  the  element  list,  then  the  system  would 
request  that  data  on  its  engagement  statistics,  sortie  rate,  etc.,  be 
entered  to  other  parts  of  the  PDB. 

If  the  second  function  type  were  selected  from  the  initial  menu 
instead  of  the  first,  the  user  would  be  ased  to: 

ENTER  'NEW'  FOR  NEW  PROBLEM  SETUP 
'OLD'  FOR  OLD  PROBLEM  RECALL 

If  'NEW'  were  entered,  a name  for  the  new  problem  would  be  requested  from 
the  user.  After  one  was  entered,  he  would  be  given  a series  of  prompts  or 
tables  to  guide  the  specification  of  an  operations  scenario.  For  expository 
purposes,  a hypothetical  problem  from  the  ONRODA  scenario  (Payne  and  Rowney, 
1975)  will  be  used.  The  decision  problem  will  be  the  construction  of  a 
strike  complement  for  a single  offensive  strike  on  the  third  day  of  Blue's 
campaign  against  Orange.  This  choice  of  problem  is  in  keeping  with  the 
suggested  capabilities  of  SCAMP-1  as  discussed  above. 

The  first  specification  requested  will  be  the  selection  of  a map 
of  the  operations  area.  The  user  will  be  asked  to: 

SELECT  MAP  CODE  - ONRODA* 


* In  all  subsequent  user-computer  communications,  the  portion  of  the  line 
underlined  is  typed  by  the  computer,  and  that  not  underlined,  by  the 

user.  If  no  portion  is  underlined,  however,  the  entire  line  is  typed 

by  the  computer.  [ j 
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either  from  a menu  of  maps  (in  the  PDB)  that  would  be  presented  by  the  system 
or  from  a manual  indicating  the  available  map  names.  Here,  the  decision- 
maker enters  the  name  of  the  map  of  the  ONRODA  operations  area.  If  the 
problem  required  no  map,  or  if  no  appropriate  maps  were  available  in  the 
data  base,  the  user  could  simply  hit  a carriage-return  to  indicate  that  no 
map  would  be  selected.  This  "not  applicable"  indication  would  be  available 
for  all  sections  of  the  scenario  definition. 

Next,  he  would  be  asked  to  define  each  Blue  and  Orange  complex  in 
the  operation  area.  These  data  would  be  entered  in  a series  of  tables  similar 
to  the  SOC  complex  definition  tables.  Each  complex  would  be  located  on  the 
map  by  the  user.  From  these  locations,  the  system  would  compute  distances 
between  complexes. 


The  user  would  next  be  asked 

to : 

DEFINE  BLUE  ELEMENTS  - KH 

(CR) 

LEAHY 

(CR) 

FI  4 

(CR) 

A6 

(CR) 

A7 

(CR) 

F4 

(CR) 

(CR) 

where  (CR)  is  a carriage  return. 

The  responses  provided  indicate  that  Kitty-Hawk  class  carriers, 
LEAHY-class  support  ships,  and  FI 4 , A6,  A7,  and  F4  aircraft  were  being  used 
by  the  Blue  force.  Each  element  type  entered  would  be  checked  by  the  system, 
to  ensure  that  data  concerning  it  were  present  in  the  PDB.  If  not,  the  user 
would  be  alerted  or  the  element  type  would  be  disallowed. 

Then  each  element  type  would  be  assigned  to  a complex  with  an  indi- 
cation of  the  maximum  number  present.  It  will  be  assumed  that  Blue  has  only 
one  complex  designated  CTF  (for  Carrier  Task  Force).  The  system  would 
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prompt  the  user: 


FOR  ELEMENT  1 KH 1 INDICATE  COMPLEX  AND  MAXIMUM 
NUMBER  AVAILABLE  - CTF,  2 

FOR  ELEMENT  1 F14 1 INDICATE  COMPLEX  AND  MAXIMUM 
NUMBER  AVAILABLE  - CTF,  20 

and  so  on.  Similar  element  definitions  and  assignments  would  be  requested 
for  the  Orange  force.  As  a final  part  of  the  scenario,  the  user  will  be 
asked  to: 


SPECIFY  TIME  FRAME  OF  INTEREST 
BEGINNING  HOUR  AND  BEGINNING  DAY  - 600,1 
ENDING  HOUR  AND  ENDING  DAY  - 240,30 


and  to 


SPECIFY  TIME-STEP  (IN  HOURS)  - 1 

This  establishes  the  entire  campaign  as  the  time  domain  of  potential  interest. 
This  will  allow  the  current  scenario  to  be  specified  once  for  the  entire  cam- 
paign, and  then  merely  "recalled"  every  time  a new  decision  problem  is  encoun- 
tered. 


All  of  the  above  information  would  then  be  stored  as  the  operations 
scenario  part  of  the  PSDB  under  the  name  supplied  at  the  beginning  of  the 
function.  If,  at  the  beginning,  the  decision  maker  had  responded  "old"  in 
order  to  recall  a previously  created  scenario,  the  information  previously 
stored  under  the  stated  name  would  be  recalled.  He  would  then  be  given  an 
opportunity  to  review  the  scenario  and  update  parts  of  it,  or  to  proceed 
directly  to  the  next  part  of  the  PS  function,  the  specification  of  a decision 
variable  and  a set  of  alternatives. 


Since  virtually  every  variable  in  the  system  is  available  to  the 
decision  maker  as  a decision  variable,  the  selection  of  a decision  variable 
cannot  be  made  from  any  simple  list  or  menu.  Rather,  the  choice  will  be 
made  through  a multi-level  selection  procedure.  At  the  most  general  level, 
the  user  will  be  asked  to  choose  the  type  of  the  decision  variable. 

SELECT  DECISION  VARIABLE  TYPE 


1.  OPERATIONS  PLAN 

2.  UNIT  DEFINITIONS 

3.  TIME  OF  ACTION 

4.  STRIKE  ROUTE 

5.  PDB  ITEMS 

These  five  categories  cover  the  range  of  decision  variables  possible. 
Depending  on  the  type  chosen,  additional  lists  will  be  presented  to  refine 
the  category.  For  the  present  problem,  the  second  item,  UNIT  DEFINITIONS, 
would  be  chosen.  A subsequent  list  would  allow  the  user  to  choose  the  name 
of  the  specific  Blue  or  Orange  unit  to  be  considered.  Here,  a Blue  unit 
named  Alpha  would  be  selected  indicating  that  the  decision  variable  for 
this  problem  was  to  be  the  composition  of  a Blue  air  unit  referred  to  as 
A1 pha. 

Next,  the  system  will  take  the  decision  maker  through  the  iterative 
specification  of  decision  alternatives.  The  construction  of  an  alternative 
requires  specifying  values  for  all  the  input  variables  required  by  the  pro- 
cess model.  At  the  very  least,  the  decision  variable  must  take  on  different 
values  in  each  of  the  alternatives.  Other  input  variables  may  be  identical 
or  different  across  alternatives,  depending  on  a variety  of  considerations. 

- For  example,  if  the  decision  variable  was  of  the  time-of-action  type,  then 

different  estimates  of  the  weather  conditions.  Blue  readiness,  and  Orange 
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readiness  would  be  required  for  each  alternative,  since  each  alternative 
represents  a different  point  in  time. 

The  system  would  direct  the  creation  of  an  alternative  by  first 
requesting  a value  for  the  decision  variable,  then  proceeding  through  all 
the  other  input  variables.  The  complete  specification  of  an  alternative 
requires  the  input  of: 

• Course  of  action  plans  for  both  Blue  and  Orange 

• Definitions  of  Blue  and  Orange  units 

• Ingress  routes  between  complexes  for  each  Blue 
and  Orange  mission- type 

• Predictions  of  weather  conditions  at  each  complex  , 

• Estimates  of  Blue  and  Orange  readiness  at  each  complex 

More  detailed  description  of  the  variables  required  is  impossible  without  a ' 

complete  specification  of  the  process  model  to  be  used  in  the  integrated  aid. 

Throughout  the  specification  of  alternatives,  the  user  would  be  able  easily 
to  indicate,  say  by  hitting  a return  key  without  entering  any  data,  that  the 
data  requested  is  the  same  as  the  data  in  the  previous  alternative  (obviously 
this  option  would  be  unavailable  in  the  construction  of  the  first  alternative). 

The  user  could  also  specify  the  data  to  be  the  same  as  in  alternative  "j" 
through  some  convention,  such  as  entering  "#j."  These  features  would  greatly 
facilitate  the  construction  of  alternatives. 

i:j 

Once  the  alternatives  had  all  been  created,  the  user  would  have  the 
ootion  of  defining  a value  model.  Since  there  are  several  different  forms 
which  the  decision  maker  might  wish  to  employ  for  the  value  model,  if  he 
chooses  to  implement  a value  model,  the  system  will  first  ask  him  to: 


SELECT  DESIRED  FORM  FOR  VALUE  MODEL 


1.  DIRECT  ENTRY 

2.  DYNAMICALLY  CONSTRUCTED 

3.  AGGREGATED- LOSSES 

Once  a form  was  chosen,  the  system  would  help  construct  the  value 
model  and  elect  parameter  values  for  it.  As  discussed  in  Section  3.3  pre- 
viously, value  models  can  be  constructed  in  at  least  three  different  ways. 

The  most  limited  perspective  is  provided  by  a direct  specification  of  a 
utility  function  by  a decision  maker  who  has  a precise,  unambiguous  and 
explicit  goal  in  mind  for  the  specific  decision  problem  at  hand.  By  select- 
ing the  first  form  listed  above,  the  user  could  choose  to  create  a utility  t 

function  himself.  This  utility  function  could  be  entered  as  any  function 
dependent  on  one  or  more  of  the  process  model  output  variables. 

At  the  other  extreme,  the  broadest  perspective  can  be  provided  by 
developing  a value  model  which  relates  the  outcome(s)  of  the  current  decision 
situation  to  the  set  of  global  objectives  for  the  overall  campaign.  This  form 
of  value  model  can  be  requested  by  selecting  the  second  item  in  the  above  list. 
The  construction  of  this  type  of  value  model  requires  a two-step  procedure  in 
which  the  decision  maker  first  defines  the  overall  campaign  objectives  and 
then  defines  the  different  kinds  of  ways  in  which  these  goals  or  objectives 

may  be  met.  The  campaign  goals  would  be  elected  through  a language  of  objec- 

tives in  which  military  objectives  can  be  stated,  focusing  on  such  concepts 
as  "destroying,"  "restraining,"  "limiting,"  "preventing,"  and  "seizing." 

Then,  the  decision  maker  would  be  asked  to  describe  deterministic  or  prob- 
abilistic relationships  between  possible  force  configurations  and  the  stated 
objectives.  The  system  then  uses  the  engagement  simulator  to  assess  the  sen- 
sitivity of  each  of  these  "final  states"  to  each  of  the  output  variables  and 

calculates  importance  weights  for  each  of  them  based  on  this  analysis.  These 
weights  would  then  be  used  as  coefficients  in  a utility  function,  constructed 
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by  the  system,  through  which  the  results  of  the  current  decision  problem 
would  be  evaluated.  This  value  model  will  then  have  been  dynamically  con> 
structed  by  using  the  process  model  to  balance  the  current  problem's  results 
against  the  user's  global  objectives. 

An  intermediate  course,  represented  by  the  last  item  in  the  above 
iist,  is  to  evaluate  the  results  of  the  specific  decision  situation  in  terms 
of  the  aggregated  damage  and  destruction  to  both  the  Blue  and  Orange  forces. 

In  this  problem  specific  form  of  the  value  model,  the  decision  maker  is  eval- 
uating the  immediate  outcome  in  terms  of  his  overall  losses  relative  to  those 
of  the  enenty  without  any  consideration  for  optimizing  the  results  with  regard 
to  long-term  objectives.  After  the  user  selected  this  form,  the  system  would 
elicit  tradeoff  values  from  the  user  for  each  of  the  Red  and  Blue  element 
types.  These  values  would  be  used  as  coefficients  in  a linear  value  function' 
based  solely  on  the  number  of  each  Red  and  Blue  unit  destroyed  or  damaged. 

The  user  would  be  asked  to: 


SPECIFY  VALUE  OF  * KH ' ELEMENT  - 100 
SPECIFY  VALUE  OF  'LEAHY'  ELEMENT  - 10 
SPECIFY  VALUE  OF  ' FI 4 ' ELEMENT  - 6 
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and  so  on.  He  would  similarly  be  asked  to  specify  values  for  each  of  the 
Orange  elements.  The  primary  difference  between  this  "aggregated-loss" 
form  of  the  value  model  and  the  "directly  entered"  form  is  that  in  the 
latter  the  user  is  not  constrained  to  consider  all  the  output  variables 
from  the  process  model,  nor  to  an  additive  linear  function  relating  them. 

In  the  directly-entered  form,  he  may  use  only  some  of  the  output  variables 
in  the  value  function  and  he  may  relate  them  in  complex  functional  forms. 

Once  the  value  model  has  been  specified,  the  decision  variables, 
alternatives,  and  value  model  will  be  saved  along  with  the  scenario  descrip- 
tion under  the  name  given  to  the  problem  as  the  complete  PSDB. 
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If  the  third  function  type  (RUN  MODEL/OBTAIN  OUTPUT)  were  selected 
from  the  initial  list,  the  system  would  first  check  to  see  if  a decision  prob- 
lem had  been  entered  to  the  system  during  the  current  run.  If  none  had,  it 
would  ask  the  decision  maker  to  supply  the  name  of  a problem  that  had  been 
previously  created  and  entered.  If  that  problem  did  not  exist  or  was  incom- 
pletely specified,  the  system  would  abort  the  function  and  force  the  execution 
of  the  PS  function. 

Once  a problem  has  been  entered  or  recalled,  the  user  would  be 
asked  to  choose  the  types  of  engagement  statistics  to  be  collected  by  the 
process  model  for  each  of  the  element- specific  output  variables.  These  out- 
put variables  will  be  displayed  to  the  user  after  the  model  is  run  in  terms 
of  the  various  statistics  chosen.  The  user  will  be  asked  to: 

' 

SELECT  ENGAGEMENT  DATA  DESIRED 

I I 

1 . ATTRITION 

a : 

2.  .LOSSES 

3.  EXCHANGE  RATIOS 

1 

and  perhaps  others.  One,  two,  or  even  all  three  of  the  statistics  could  be 
chosen. 


The  system  would  then  ask  the  user  to: 
SELECT  ACTION 

1.  RUN  SIMULATOR 

2.  RUN  SENSITIVITY  ANALYSIS 

3.  RUN  OPTIMIZER 

4.  ENTER  WAR-GAME  MODE 
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5.  END  FUNCTION 


and  possibly  others.  If  the  simulator  (process  model)  were  run,  the  system 
would  use  the  data  in  the  PSDB  to  form  inputs  to  the  model  and  to  identify 
the  additional  data  needed  from  the  PDB.  If  the  data  needed  from  the  PDB 
were  found  to  be  missing  or  erroneous,  the  decision  maker  would  be  notified 
and  given  the  option  of  aborting  the  run  or  having  the  model  use  default 
estimates  of  the  bad  data.  Once  all  the  inputs  were  formed,  the  model  would 
then  be  exercised  for  each  alternative  in  the  PSDB. 

When  the  runs  were  completed,  the  decision  maker  would  be  asked 
to  select  output  variables  for  display  from  a list  containing  all  the  output 
variables.  As  with  the  inputs,  an  exact  list  of  the  outputs  cannot  be  given 
without  a detailed  specification  of  the  process  model,  but  the  list  would 
Include  overall  utilities  and  some  detailed  mission  achievement  results. 

When  a specific  Orange  or  Blue  element  was  selected  for  display,  it  would  ' 
be  displayed  according  to  each  of  the  statistics  selected  by  the  user  before 
the  model  was  run.  For  example,  if  the  only  statistic  chosen  was  ''attrition" 
and  the  user  requested  a display  of  the  FI 4 output  variable,  the  system  would 
present  the  process  model's  estimate  of  the  FI 4 attrition  that  would  obtain 
In  strikes  launched  with  each  alternative  configuration  of  the  Alpha  unit. 

Once  the  user  has  viewed  all  the  output  variables  of  interest,  he  could  return 
to  the  SELECT  ACTION  list  and  try  a different  analysis  feature  or  he  could 
end  the  function. 

When  the  END  FUNCTION  option  Is  selected  from  the  SELECT  ACTION 
list,  the  system  returns  the  user  to  the  original  SELECT  FUNCTION  menu. 

When  a request  to  STOP  Is  entered  from  that  menu,  the  system  checks  to  see 
If  there  Is  an  unsaved  version  of  an  old  or  new  decision  problem  In  the  PSDB. 
If  there  is,  it  gives  the  user  the  option  of  saving  it.  This  would  also  be 
done  if,  upon  returning  to  the  SELECT  FUNCTION  menu,  the  ENTER/RECALL  DECISION 
PROBLEM  function  were  selected  again. 
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Within  this  kind  of  organization,  the  existing  display  features 
of  the  ASTDA,  SOC,  EWAR,  and  ROUTE  PLANNER  aids  could  even  be  maintained 
as  they  are.  The  new  software  would  largely  consist  of  table-driven  algo- 
rithms to  identify  the  permitted  displays  or  tables  at  various  points  in  the 
program,  to  identify  the  data  necessary  for  processing  to  continue,  and  to 
monitor  the  PDB  and  PSDB  to  ensure  that  no  step  begins  or  proceeds  without 
the  required  data. 
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